-
Notifications
You must be signed in to change notification settings - Fork 0
WIP: Add Nix build infrastructure with Crane #12
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
base: main
Are you sure you want to change the base?
Conversation
The existing CI relies on system-installed toolchains and Docker images that can stop working unexpectedly, leading to build failures or subtle differences between developer machines and CI. This makes debugging difficult and wastes time chasing environment issues. Nix provides fully reproducible builds by pinning exact versions of the Rust toolchain, system libraries, and all dependencies. Every developer and CI runner builds with identical environments, ensuring that if it builds locally, it builds everywhere. Crane handles Rust-specific concerns like dependency caching and cross-compilation. Combined with the Determinate Systems GitHub Actions, builds are cached efficiently across CI runs. A justfile provides simple commands for developers unfamiliar with Nix syntax, making the transition seamless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 48dc0cdad2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # Native Linux builds: use mold for faster linking | ||
| [target.'cfg(target_os = "linux")'] | ||
| rustflags = ["-C", "link-arg=-fuse-ld=mold"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid forcing mold for Linux builds without providing it
All Linux targets now inherit -fuse-ld=mold, but the Nix cross/musl packages only add pkg-config to nativeBuildInputs (see mkCrossPackage/mkMuslPackage in flake.nix) and Nix builds run in a pure environment. That means nix build .#x86_64_unknown_linux_musl or .#aarch64_unknown_linux_musl will fail at link time because mold is not in PATH. Either scope the mold flag to builds that include mold, or add mold to the cross/musl build inputs.
Useful? React with 👍 / 👎.
flake.nix
Outdated
| # Copy the shared library with NAPI-RS naming convention | ||
| if [ -f target/release/liblightning_js.so ]; then | ||
| cp target/release/liblightning_js.so $out/lib/lightning-js.linux-x64-gnu.node | ||
| elif [ -f target/release/liblightning_js.dylib ]; then | ||
| cp target/release/liblightning_js.dylib $out/lib/lightning-js.darwin-x64.node |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Name macOS arm64 artifact correctly
The install phase always renames a macOS dylib to lightning-js.darwin-x64.node. On macOS arm64 runners (e.g., macos-14 in the new workflow), this produces an arm64 binary labeled as x64, which downstream packaging/consumers will mis-detect. Use the actual target architecture (e.g., darwin-arm64) when building on arm64.
Useful? React with 👍 / 👎.
Added nativeNodeName mapping to determine correct NAPI-RS addon filename based on localSystem (x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin). This ensures Apple Silicon builds produce correctly named darwin-arm64.node files instead of being mislabeled as darwin-x64. Fixed musl builds failing with "target does not support cdylib": - Changed +crt-static to -crt-static for musl targets - Static CRT is incompatible with shared library (cdylib) output - Musl addons now dynamically link to musl.so Fixed cross/musl builds failing to find mold linker: - Added mold to nativeBuildInputs for mkCrossPackage - Changed CARGO_BUILD_RUSTFLAGS to RUSTFLAGS (priority #2) to override config.toml's target-specific flags (priority #3) - Include mold flag in RUSTFLAGS for musl/cross builds
Fixed Darwin builds failing with "apple_sdk_11_0 has been removed": - Migrated from darwin.apple_sdk.frameworks to apple-sdk.frameworks - Updated MACOSX_DEPLOYMENT_TARGET from 10.13 to 11.0 Updated GitHub Actions workflow: - Removed macos-13 runner (retired by GitHub) - macOS builds now use macos-15 (arm64 only)
Consolidate repeated patterns and improve organization: - Extract mkNativePackage helper for release/debug builds - Unify mkCrossPackage to handle both glibc and musl targets - Scope check-only definitions (checkBuildInputs, cargoArtifacts) into a local let block within the checks output - Extract mkInstallPhase and mkCrossInstallPhase helpers - Remove dead code: unused profile variable, no-op conditionals - Fix Darwin builds: use darwin.apple_sdk.frameworks path - Update formatter from deprecated nixfmt-rfc-style to nixfmt
Remove darwin.apple_sdk.frameworks references which have been removed from nixpkgs as legacy compatibility stubs. The default SDK now includes Security and SystemConfiguration frameworks automatically. Remove explicit MACOSX_DEPLOYMENT_TARGET since it was out of sync with the nixpkgs SDK default (14.0). Let nixpkgs use its default darwinMinVersion which matches the SDK. Update CI to use 'default' package for x86_64 glibc builds since the native build on ubuntu runners is the x86_64-unknown-linux-gnu target. Add upfront evaluation check with --all-systems --no-build to catch cross-platform issues like this before running full builds.
Use find to locate liblightning_js.so/.dylib instead of hardcoding the target directory path. Crane's build environment may place outputs in different locations than a regular cargo build. Consolidate mkInstallPhase and mkCrossInstallPhase since both now use the same find-based approach.
Extracted buildDepsOnly derivations for all targets so dependencies are cached separately from source code. When only source changes, subsequent builds skip dependency compilation entirely. - Native release package and checks share nativeCargoArtifacts - Debug builds use separate debugCargoArtifacts (different profile) - Cross and Android targets each cache their own dependencies - Refactored to use shared commonArgs patterns
Removed armv7-linux-androideabi build target from both the Nix flake and GitHub Actions workflow. This 32-bit ARM target is increasingly rare on modern Android devices. Added max-parallel: 3 to the Linux build matrix to reduce concurrent jobs hitting the GitHub Actions Cache, which was causing Magic Nix Cache throttling errors (HTTP 418).
Merge the separate build-android job into build-linux by adding aarch64_linux_android to the target matrix. This simplifies the workflow and reduces duplication. Also refactor build-macos to use a matrix pattern for consistency and future extensibility. Remove max-parallel limit from build-linux to allow faster CI runs.
Add max-parallel: 1 to build-linux matrix to prevent concurrent jobs from overwhelming the Magic Nix Cache. Refactor mkInstallPhase to properly detect missing library files and fail with a clear error message instead of silently succeeding.
The existing CI relies on system-installed toolchains and Docker images that can stop working unexpectedly, leading to build failures or subtle differences between developer machines and CI. This makes debugging difficult and wastes time chasing environment issues.
Nix provides fully reproducible builds by pinning exact versions of the Rust toolchain, system libraries, and all dependencies. Every developer and CI runner builds with identical environments, ensuring that if it builds locally, it builds everywhere.
Crane handles Rust-specific concerns like dependency caching and cross-compilation. Combined with the Determinate Systems GitHub Actions, builds are cached efficiently across CI runs.
A justfile provides simple commands for developers unfamiliar with Nix syntax, making the transition seamless.