Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
* use default stdenv (clang 7)
* add no-arc.patch to make the xcode_locate tool compile without libarc-lite
* remove the `-mmacosx-version-min=10.9` flag from the bootstrap compile script
Use the same JDK for building bazel and for its runtime.
Effectively, the former `toolchain_hostjdk8` java toolchain has been deprecated
and should no longer be used (in newer bazel)[1]:
```
# Deprecated, do not use.
# It will be removed after migration to Java toolchain resolution.
default_java_toolchain(
name = "toolchain_hostjdk8",
...
)
```
[1]: 4fc4868065/tools/jdk/BUILD.tools (L384-L387)
These are fixes for problems I ran into with:
- `bazel test //example:cpp-test`
This needed `build --host_javabase='@local_jdk//:jdk'`
- `bazel query 'deps(//example:cpp-test)'`
This needed the same flags as `build`.
Is it contentious to (partially?) configure the default java toolchain? I don't see it as much different than providing the bazel server's java.
It would continue to be configurable/overridable by overriding the flags.
---
And a random notes from this escapade, but https://github.com/bazelbuild/bazel/blob/master/WORKSPACE#L144-L308 looks a little different from https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel/bazel_3/src-deps.json so one of them is probably wrong :)
Limit the resources Bazel is allowed to use during the build to 1/2 the
available RAM and 3/4 the available CPU cores. This should help avoid
overwhelming the build machine.
Preserving existing behavior: the bash completion was not executable,
the zsh completion was; according to lukegb the fish completion does
not have to be executable.
