-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
nodejs: use ninja for build #327653
nodejs: use ninja for build #327653
Conversation
done | ||
fi | ||
''} | ||
$AR -cqs $libv8/lib/libv8.a @files |
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.
Note: before this change, we had fallback for ar
that does not support response files. As far as I know, that is only the case for Darwin’s cctools, but stdenv already uses LLVM for most of the tools on Darwin.
isCCTools = true; # The fact ld64 is used instead of lld is why this isn’t `isLLVM`. |
That is, I think we can assume that ar
supports response files (unless there is some edge case I’m missing).
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.
In the future, ideally, we should update v8 package and avoid using nodejs as v8 library provider.
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.
You could set env.AR
to "${lib.getBin llvm}/bin/llvm-ar"
to play it really safe, but that’s not necessary.
Darwin bintools has been using llvm-ar
since 23.11. Going forward, more tools will be switched to their LLVM versions as compatibility and stability improve. None are expected to switch back to their cctools versions.
f299a8e
to
711c32a
Compare
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.
Just tested that on a aarch64-darwin machine:
$ nixpkgs-review pr --checkout commit --package nodejs_18 --package nodejs_20 --package nodejs_22 327653
6 packages built:
nodejs_18 nodejs_18.libv8 nodejs_20 nodejs_20.libv8 nodejs_22 nodejs_22.libv8
+ "--show-sdk-platform-path": "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform", | ||
+ "--show-sdk-path": "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk", |
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.
How does this work with the build sandbox?
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.
Node.js has two copies of GYP and this change just extends the existing patch to the second GYP copy. This works fine with sandbox, but I'm not really sure how that's supposed to work without sandbox since technically nothing stops the build from accessing these paths.
Anyway, this allows us to drop xcbuild from Node.js native build inputs with minor copy-paste modification to an existing patch. I'm leaving refactoring or documenting this behavior to my future self (e.g. if we add split dev output, we can use fake xcbuild in propagatedNativeBuildInputs instead of patching GYP).
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.
Do you know if this fixes the weird double‐compilation test race condition, or is that still yet to be diagnosed?
Not yet, but I think Node.js had the same issue that they fixed by limiting Make parallelism: nodejs/node#22006 (comment) We are not using |
Force-pushed to minimize formatting changes (see #327653 (comment)). |
else if platform.isLoongArch64 then | ||
"loong64" | ||
else | ||
throw "unsupported cpu ${platform.uname.processor}"; |
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.
This is not an idiomatic Nixpkgs pattern and should probably use some fallback for unknown platforms instead of throwing an error. I’m keeping it for now and will address this in subsequent code style PRs.
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.
It's fine to throw if we don't know the platform.
env = { | ||
# Tell ninja to avoid ANSI sequences, otherwise we don’t see build | ||
# progress in Nix logs. | ||
NINJA = "TERM=dumb ninja"; |
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.
Not setting TERM=dumb
globally because Node.js v18 needs nodejs/node@f76b28f backport.
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.
We should write that into a comment
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.
Hmm, this is unfortunate. I think Nix build environments have enough of a PTY to run these tests, but we’re using TERM=dumb
to get Ninja to give us more detailed output. It’d be nice if we could still run those tests, but it’s probably not that important.
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.
These tests run fine unless TERM=dumb
is set 😅
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.
Yeah. We could override TERM
for just those tests, but it’d be ugly. I’m guessing Ninja has probably already been approached about an alternate way to toggle non‐fancy build output and maybe rejected it. Oh well.
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.
Filed ninja-build/ninja#2475.
@emilazy, I’ve added a commit that should fix races in check phase. |
Thanks! Do you think there’s any chance of splitting off the tests into a separate derivation like you suggested? Maybe that should wait for a second PR… I can test this on |
Yes, thanks, the PR is ready. I’ve run built the package a few times on aarch64-darwin and didn’t notice any issues. Note:
The change set of this PR is complete and I’d like to avoid adding more unrelated changes. |
@emilazy, it’s ready for review and tests, hopefully ofborg-eval error will go away after force push (it’s not caused by changes in Node.js package). Let’s wait for green checkmark on the commit before testing this again, otherwise I’d have to rebase staging branch… Last time I’ve tested this PR on |
The Hydra macOS builders have the sandbox turned off, so if we want to stop the Node.js packages being so flaky on them we’ll need to figure out what’s going on there. |
Hm, I can’t reproduce build failure on |
I’ve installed macOS on my old Intel MacBook, it’ll take some time to build stdenv (oof dual core CPU), but hopefully I’ll be able to test this PR on x86_64-darwin by the end of this week. |
I can reproduce That said, these tests were failing before changes in this PR (they were disabled before and we revert that in d7f46fb), so I’m adding them to the list of disabled tests for x86_64-darwin. |
Sometimes this isn’t possible due to conflicts, but I would generally recommend basing your Going to try these builds out now (…rebased onto |
# See https://github.com/nodejs/node/issues/22006 | ||
enableParallelChecking = false; |
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.
It seems like upstream hasn’t seen any issues here for years and closed this issue as a result. I’m wondering if it really is an upstream issue, but if so, it’d be good to ping the issue with example logs to hopefully get it reopened (and maybe even fixed).
Successfully built |
Failed on the
The full list:
Running again with the sandbox off. |
Uh, actually I think that was with |
The slim variants build fine on |
The slim variants build fine on |
Does Nix actually use |
It does as long as you are in (Corollary: You can use |
Okay, both Node.js 18 variants went through on I do worry that the potential hint of test flakiness when builds are run in parallel (a common theme with loopback networking tests) will mean further Hydra build failures and result in us having to turn tests off on Darwin again, but I’m willing to chance it. (We could at least just turn those specific tests off if it ends up being necessary rather than the whole suite.) |
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.
It succeeded. This PR has gone on for long enough. Let’s ship it!
Build
Any idea why? |
Well, we have an outdated v8 package in Nixpkgs and #147506 introduced a libv8 output for Node.js package with v8 static library. I haven’t really touched libv8 part in this PR aside from removing special case for nixpkgs/pkgs/development/web/nodejs/nodejs.nix Lines 346 to 351 in 7cef6cd
|
This is no longer required because upstream merged: NixOS/nixpkgs#327653
Description of changes
This PR contains changes to build Node.js without cross-compilation (see #220204 (comment)) and use ninja for build.
Note that we can’t use
--cross-compiling
with Ninja without nodejs/gyp-next#185, but we don’t have to because we use an emulator instead. This is based on Buildroot’s 0001-add-qemu-wrapper-support.patch patch, but re-implemented in a manner that hopefully can be upstreamed (see also nodejs/node#53899).Supersedes
Fixes
Things done
gcc.arch = "armv6kz"
andgcc.fpu = "vfpv2"
)nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.