cc @mboes @xeji

Would be nice to figure out why this isn't passing on CI so we could get it checked.

@GrahamcOfBorg build bazel

No attempt on aarch64-linux (full log)

The following builds were skipped because they don't evaluate on aarch64-linux: bazel

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

Failure on x86_64-darwin (full log)

Attempted: bazel

./tools/test/collect_coverage.sh: interpreter directive changed from "/bin/bash -x" to "/nix/store/xain263p9gxvb4h2a3cy2836k872qcgx-bash/bin/bash -x"
./tools/test/test-setup.sh: interpreter directive changed from "/bin/bash" to "/nix/store/xain263p9gxvb4h2a3cy2836k872qcgx-bash/bin/bash"
configuring
no configure script, doing nothing
building
Building Bazel from scratch....../usr/bin/xcrun clang -fobjc-arc -framework CoreServices -framework Foundation -o /tmp/bazel_FJVCFHwC/archive/_embedded_binaries/xcode-locator tools/osx/xcode_locator.m
xcode-select: error: no developer tools were found at '/Applications/Xcode.app', and no install could be requested (perhaps no UI is present), please install manually from 'developer.apple.com'.
/nix/store/7amnc2662p390bgzj6c0snylj19vxmj2-stdenv-darwin/setup: line 1291: ./output/bazel: No such file or directory
builder for '/nix/store/rwkfqqn0i34bp81qdqk6y6zfymry0pfk-bazel-0.13.0.drv' failed with exit code 127
�[31;1merror:�[0m build of '/nix/store/rwkfqqn0i34bp81qdqk6y6zfymry0pfk-bazel-0.13.0.drv' failed

Success on x86_64-linux (full log)

Attempted: bazel

//examples/cpp:hello-success_test                                        PASSED in 0.1s
//examples/java-native/src/test/java/com/example/myproject:hello         PASSED in 0.2s

Executed 2 out of 2 tests: 2 tests pass.
There were tests whose specified size is too big. Use the --test_verbose_timeout_warnings command line option to see which ones these are.
installing
post-installation fixup
patching script interpreter paths in /nix/store/86m11yd46llr0fcqhgv991ymirshhdkz-bazel-0.13.0
checking for references to /tmp in /nix/store/86m11yd46llr0fcqhgv991ymirshhdkz-bazel-0.13.0...
/nix/store/86m11yd46llr0fcqhgv991ymirshhdkz-bazel-0.13.0

Looks pretty much like the same error as without this PR: https://hydra.nixos.org/build/76471773

Yes, as I mentioned in #40525 (comment) it's because Xcode isn't installed on the hydra machines. The error this PR fixes appears much later.

I know little about Mac infrastructure, but if this package needs Xcode to build, why isn't Xcode listed as a dependency?

I never realised because it works on my machine, I just checked and it's because the path to xcrun is hardcoded here:

https://github.com/bazelbuild/bazel/blob/09222fac7c8851d26e44e087a6beb4ce2ed5dc39/scripts/bootstrap/compile.sh#L317

which isn't too bad since on macOS that should be there even if you don't have Xcode installed, though it might prompt you to install the Command Line Developer Tools for Xcode package.

Note that even the xcodeenv Nix derivation uses /usr/bin/xcrun:

https://github.com/uri-canva/nixpkgs/blob/7ceafa575a06880ad6d2e8328a4ec986bb7db1e0/pkgs/development/mobile/xcodeenv/xcodewrapper.nix#L11

so using it is unnecessary to make this work on macOS, and it still won't fix the build on hydra.

which isn't too bad since on macOS that should be there even if you don't have Xcode installed, though it might prompt you to install the Command Line Developer Tools for Xcode package.

If these Command Line Developer Tools are required to build bazel, they should be listed as a dependency IMO. However, this may prevent ofborg and hydra builds since they're probably unfree.

@matthewbauer how should we handle this?

Oh that's not good. You're not allowed to use Command Line Tools in Nixpkgs due to licensing issues. We unfortunately do not have a good sandbox available to enforce this. (/cc @copumpkin @LnL7)

Can someone mark this as broken until we can figure out a pure solution? Bazel should let us build without an Xcode SDK, which would be very much preferred. If not possible, we should try passing in xcbuild which has the fake SDK that I made.

Yeah, there's basically nothing in the official command-line tools that we don't provide in nixpkgs, so I'd be surprised if they were formally necessary for this. Of course, Bazel is notorious for hardcoding paths to shit 😄

Your xcbuild fake xcrun might be our best bet here, assuming Bazel is a good-enough citizen to respect SDKs and the like, and isn't just hardcoding /usr/bin/cc and the like.

Is there a way I can trigger builds on hydra or is there a darwin NixOS image I can install in VM to test some changes? It's possible we can avoid the use of xcrun by calling directly to clang or other tools as noted in

https://github.com/uri-canva/nixpkgs/blob/7ceafa575a06880ad6d2e8328a4ec986bb7db1e0/doc/platform-notes.xml#L63

I can also try out using xcbuild, but I still would need a way to test the changes.

It's doing some crazy stuff I've never seen before:

https://github.com/bazelbuild/bazel/blob/20a042faa91acf8db78684de9f38c4e628d61dd6/tools/osx/xcode_locator.m

I think the installation process builds that file, but never executes the resulting binary, so it's ok to build it in a pure way:

https://github.com/bazelbuild/bazel/blob/09222fac7c8851d26e44e087a6beb4ce2ed5dc39/scripts/bootstrap/compile.sh#L317

The comment in https://github.com/bazelbuild/bazel/blob/09222fac7c8851d26e44e087a6beb4ce2ed5dc39/scripts/bootstrap/compile.sh#L314
suggests it's needed somewhere .

Yes, it's only needed here though:

https://github.com/bazelbuild/bazel/blob/dfa8dcde7388d0f57c2e2f21d96f388a566a4fb6/src/main/java/com/google/devtools/build/lib/exec/apple/XcodeLocalEnvProvider.java#L94

conditional on the environment having an Xcode version override. Following the thread of that data through the code, I think it's originally set here:

https://github.com/bazelbuild/bazel/blob/b0440164eda858fa0e14f623780a00b30e20ebf7/src/main/java/com/google/devtools/build/lib/rules/apple/AppleCommandLineOptions.java#L76

so it's only necessary if you specify an Xcode version other than the currently selected default, and Bazel has to find where that Xcode is, so it runs the xcode-locator tool.

So it's needed to run Bazel correctly in the general case, but it's not needed to run Bazel inside Nix, either during its own build and install phase or when used to build other derivations.

So we could just patch https://github.com/bazelbuild/bazel/blob/09222fac7c8851d26e44e087a6beb4ce2ed5dc39/scripts/bootstrap/compile.sh#L316

to always use the xcode_locator_stub.sh, even on darwin.

No, because then the resulting Bazel would not support --xcode_version even when run outside of Nix.

We can patch it to run clang from nix instead of /usr/bin/xcrun clang though, which should build the xcode-locator tool correctly.

As I mentioned above I have no way of testing all these changes though. Is the darwin image used in hydra available anywhere?

Also can we get this PR merged in the meantime? It fixes something that was working before #40525 was merged, and doesn't regress anything else.

Yeah sure just be aware that this will break once sandboxing is reenabled.

As I mentioned above I have no way of testing all these changes though. Is the darwin image used in hydra available anywhere?

Sorry, don't know. Worst case is you open a new PR and we let ofborg test it for you 😄

@uri-canva Nothing special about it, just an empty machine without the CLT or Xcode installed. The nix installer doesn't have any system dependencies beyond curl/tar unlike eg. homebrew.

$ /usr/bin/git
xcode-select: error: no developer tools were found at '/Applications/Xcode.app', and no install could be requested (perhaps no UI is present), please install manually from 'developer.apple.com'.