-
-
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
bazel: fix darwin build on hydra #44181
Conversation
There is an interesting issue here: should the Bazel derivation declare all the Nix tools as dependencies? The resulting Bazel is fine to use without the Nix tools as long as no c/c++ code is built, or c/c++ code is built using custom It might be hard to find out which dependencies to use in your profile to use the default |
The xcode_locator is still an issue though, right? The Hydra machines definitely don't have Xcode installed. I feel like that should be the focus - everything else is basically the same between linux & darwin. IIRC enableNixHacks will make sure NIX_LDFLAGS & NIX_CFLAGS_COMPILE are available. We might just need to make that default to true on Darwin or maybe even Linux as well for consistency. It might be better to try to upstream that match and make it conditional on some flag. The xcode_locator.m thing is something that might be worth trying to convince Bazel maintainers is a VERY bad idea. They use |
I will take a look on Monday. Please ping me if I forget. |
There are two xcode_locator related issues: one is that it's built during bootstrapping by hardcoding the compilation command: |
zip | ||
python | ||
unzip | ||
makeWrapper | ||
which | ||
customBash | ||
] ++ lib.optionals (stdenv.isDarwin) [ libcxx CoreFoundation CoreServices Foundation ]; | ||
binutils | ||
] ++ lib.optionals (stdenv.isDarwin) [ cctools clang Libsystem libcxx CoreFoundation CoreServices Foundation ]; |
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.
https://github.com/NixOS/nixpkgs/pull/42832/files#r199536836
Clang shouldn't be needed - it will be provided by stdenv.
Is there no way of having a stdenv with gcc instead of clang on darwin? If so, should I replace all instances of ${clang}
with ${stdenv.cc}
?
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.
yes, gccStdenv
or clangStdenv
for the reverse on linux.
b91fad3
to
8938d9d
Compare
Found out I misunderstood the purpose of the absolute paths in |
ping @Profpatsch |
@GrahamcOfBorg build bazel |
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: bazel Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: bazel Partial log (click to expand)
|
Success on x86_64-darwin (full log) Attempted: bazel Partial log (click to expand)
|
tbh I can’t say much about Darwin patches (no machine). But it looks like at least it builds on Darwin now. Adding a test might be a good idea. Can you please add some comments to the bash code lines, explaining why the respective lines are needed? It seems to require some pretty arcane knowledge, so better document too much then too little. If you can, please shorten the lines a bit as well. |
Will add comments.
What kind of test? Doesn't the darwin build cover testing this? |
Ah, I mean some test that runs a simple build with bazel to check if it actually runs, not just builds. |
8938d9d
to
07254df
Compare
@Profpatsch Added comments.
We already do that by building and running the example tests:
|
That looks awesome! @mboes, I think we can merge? |
ping @mboes |
I will just merge now, feel free to revert if something’s not right. |
Motivation for this change
This fixes the build to not build c/c++ code using system tools referred to with absolute paths in
/bin
and/usr/bin
, allowing Nix to build Bazel on macOS without having Xcode installed.This is important to allow hydra to build Bazel, and submit a prebuilt derivation to the binary cache.
Originally merged in #42832, reverted in #43479.
This PR takes a different approach: instead of fixing the build of Bazel, it changes the built Bazel to refer to Nix tools instead of system tools. The previous PR would allow Nix to build Bazel using Nix tools, but the built Bazel would use system tools.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)