#Multimc 5 lwjgl 3 windows

One problem is that I don't have any hardware to test on, but I'm getting:ĭumpbin /HEADERS glfw.dll | findstr machine

#Multimc 5 lwjgl 3 windows

Ideally, replace them with your own upload procedure to test the artifacts.Īs a test, I got GLFW to build on Windows ARM64 and macOS ARM64. Before opening a PR and while testing a new build, you probably want to comment out the awscli installation and aws s3 cp commands, to avoid build errors. Artifacts are uploaded to LWJGL's S3 build bucket. Each build file contains a matrix of builds for the various architectures. We use Travis CI for Linux and macOS builds, AppVeyor for Windows builds. travis.yml and appveyor.yml (note: we completely overwrite those files if they exist in the upstream project). There are two interesting files in each CI commit.

This keeps the history clean and enables interested users to easily identify in which state each binding has been built (it's always the HEAD~1 commit). When the binding is updated, the CI commit is rebased on top of the new upstream commit. This commit includes the build scripts and any fixes that need to be applied. Each repository has a single 'LWJGL CI' commit on top of the upstream commits. We have a separate account for CI ( LWJGL-CI). Could you please confirm and check if they use anything else? Those most likely include: GLFW, OpenGL, OpenAL and stb. We could focus on bindings that Minecraft uses first, deal with the rest later. I'm guessing that Microsoft is mostly interested in getting Minecraft to run on ARM64. In any case, we don't need every dependency to release LWJGL and our build customizer can handle platforms/architectures with missing bindings.

Some will be trivial to build, others may require simple fixes we can apply on our own, sometimes we may have to wait for the upstream maintainers to do the work. LWJGL has a simple core that's easy to build, but the different bindings depend on native libraries with varying implementation quality and build complexity. Porting LWJGL means getting the CI pipelines to build its native dependencies for the new platform/architecture.