Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI Pre-build and download #115

Open
konsumer opened this issue Feb 23, 2022 · 4 comments
Open

CI Pre-build and download #115

konsumer opened this issue Feb 23, 2022 · 4 comments
Labels
raylib4 Issues related to migration from raylib 3.5 to 4.

Comments

@konsumer
Copy link
Collaborator

konsumer commented Feb 23, 2022

We could speed up install with CI builds for lots of targets, and download on install, or just include many with the npm module.

I think some good targets would be:

  • osx intel 64bit
  • osx M1
  • windows intel 64bit
  • linux intel 64bit

and then, maybe as secondary targets:

  • windows intel 32bit (I dunno if anyone uses this...)
  • linux arm 32bit (pi)
  • linux arm 64bit (pi4)

On any targets not covered, it should work the same as it does now, so it's really just a way to speed it up (and not require cmake/c tools/build-time) on most the common platforms.

@konsumer konsumer added the raylib4 Issues related to migration from raylib 3.5 to 4. label Feb 23, 2022
@konsumer
Copy link
Collaborator Author

Looks like we already have some CI in place. I am going to do some local testing with act to see if I can improve it, and get it building for more targets, then work on the entry-point to prefer a pre-built from CI over cmake-built.

@konsumer
Copy link
Collaborator Author

konsumer commented Feb 23, 2022

I started work on this with a fancier build-matrix. I also merged test & build to optimize cacheing, and set it to run on every push/PR, so we have a nice test indicator & build to play with on every platform.

Screen Shot 2022-02-23 at 10 08 32 AM

remaining issues

  • I had to skip a few tests. Not sure if they worked before raylib4, but they should get a closer look.
  • I can easily matrix node-version & OS, but not arch. Arch can sort of be handled with this but only for linux, so that leaves out mac M1 & non-64bit windows. M1 users should be good with rosetta, but maybe they should just use native cmake fallback, too. I think it's fine, as long as the build script works, but it might make sense to add a separate pi build (maybe just on tagged release?) since it is very slow to build there.
  • still need to work out how to use these build artifacts in the library. I setup CI so it skips things like npm's postinstall, so we can use that hook to check & download things (and build if needed.) Normally I would use tag to setup a release and npm publish and point to latest release, but maybe we want to set this up differently?
  • do we need to test all these node versions? supporting just 16.x would simplify & speedup (3X) and should basically apply to the older versions. They seem to produce interchangeable .node files.

@RobLoach
Copy link
Owner

That's awesome! Nicely done.

@konsumer
Copy link
Collaborator Author

I added a stub setup in tools/postinstall.js. It will load very fast if you have build/Release/node-raylib.node and download a tagged release if we have one (from CI) or build it, if not. It only installs build-tools if you actually need to build, so people on a supported platform will be able to use it, even if they don't have cmake/etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
raylib4 Issues related to migration from raylib 3.5 to 4.
Projects
None yet
Development

No branches or pull requests

2 participants