-
-
Notifications
You must be signed in to change notification settings - Fork 13.8k
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: Don't hardcode build tools #42552
Conversation
Bazel is a build tool, much like Make and many others. Like Make, it should be agnostic to the compiler toolchains the user brings into scope. Bazel has special rules that encode domain specific knowledge for how to compile a C++ program, or indeed a Java program and a few others. But that's not to say that at runtime Bazel should assume a specific C++ compiler or Java compiler anymore than Make does. The main impact of this change is that packages that build with Bazel will have to list the compilers they want in their `buildInputs` or similar, rather than relying on the `bazel` package pulling them in transitively.
@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)
|
Failure on x86_64-darwin (full log) Attempted: bazel Partial log (click to expand)
|
installPhase = '' | ||
mkdir -p $out/bin | ||
mv output/bazel $out/bin | ||
wrapProgram "$out/bin/bazel" --prefix PATH : "${lib.makeBinPath [ stdenv.cc jdk ]}" | ||
wrapProgram "$out/bin/bazel" --set JAVA_HOME "${jdk}" |
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.
Why leave the wrapper for JAVA_HOME
? By the same logic (which I agree with) JAVA_HOME
should be set by the caller as 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.
Ah sorry I'm silly, this is for the JAVA_HOME
used to run Bazel, not the one used to build java projects with Bazel.
Bazel is a build tool, much like Make and many others. Like Make, it
should be agnostic to the compiler toolchains the user brings into
scope. Bazel has special rules that encode domain specific knowledge
for how to compile a C++ program, or indeed a Java program and a few
others. But that's not to say that at runtime Bazel should assume
a specific C++ compiler or Java compiler anymore than Make does.
The main impact of this change is that packages that build with Bazel
will have to list the compilers they want in their
buildInputs
orsimilar, rather than relying on the
bazel
package pulling them intransitively.