Comments on conflicts:
- llvm: d6f401e1 vs. 469ecc70 - docs for 6 and 7 say the default is
to build all targets, so we should be fine
- some pypi hashes: they were equivalent, just base16 vs. base32
By changing the default toolchain to JDK8, we broke the default Java
toolchain, which assumes JDK9.
Instead, set `host_java_toolchain` manually for our build of bazel,
and set `java_toolchain` to run the java tests with the build JDK as
well.
Fixes https://github.com/NixOS/nixpkgs/issues/54289
Unfortunately the tarball was modified for the official release and
"nix-store -r --check $(nix-instantiate -A scons.src)" did not catch
this (not sure why ATM).
Thanks @pbogdan for noticing this :)
Since the 0.21 upgrade, the host `$PATH` is not forwarded anymore by
default to the sandboxes in charge to realize Bazel actions. This
default change broke the `py_binary` rule among other things.
Every python binary is wrapped in a stub in charge to setup the
execution environment. Currently, this stub's shebang points to a
`/usr/bin/env python` which cannot be resolved with the current
`$PATH`.
This results in breaking any build pipeline requiring the use of
python at some point. On top of the incorrect shebang, the stub
template is unable to find the actual python binary using
`SearchPath`.
This PR fixes those two things by re-writing the stub template shebang
to the actual python binary and by substituting the faulty default
python binary lookup to the right one.
ninja sources include re2c's output files, so unless we change the sources by applying a patch, re2c is not even launched
anyway, it is not relevant to building docs
0.21 removed the bundled openjdk-distribution. Instead, tries to fetch
the “right” distribution on-the-fly when building.
So we need to provide our own openjdk.
According to
https://github.com/bazelbuild/bazel/issues/6865#issuecomment-447261288
we should set `--host_javabase="@local_jdk//:jdk` if we want to do
that. This uses the jdk that is currently in the environment, which is
openjdk 8 in our case. 0.21 defaulted to a toolchain for JDK9, which
we don’t package in nixpkgs, so we use the JDK8 toolchain.
This commit also replaces the line-number-based sed invocations with
something more stable.
Bazel runs actions in a sandbox by default on Darwin and Linux.
However, the sandboxing was always and *silently* disabled previously,
because a Bazel feature test was always failing. The feature test
involved running `/bin/true` inside a sandbox. But on NixOS,
`/bin/true` does not exist...
This change is going to be required when upgrading to Bazel 0.20.0,
because in the checkPhase we're not wrapping the Bazel binary yet to
set some necessary default arguments.
gnumake can support subsecond mtimes if it is available. But Darwin
doesn’t support setting subsecond mtimes until 10.13! So we can just
disable this check to avoid the issue where most of our built tools
use seconds but make uses nanoseconds. Might fix some parallel issues
along the way.
Fixes#51221
To make updating large attribute sets faster, the update scripts
are now run in parallel.
Please note the following changes in semantics:
- The string passed to updateScript needs to be a path to an executable file.
- The updateScript can also be a list: the tail elements will then be passed
to the head as command line arguments.
Things changed in the Ninja setup-hook:
- Respect installFlags
- Automatically add checkPhase (can be disabled with dontUseNinjaCheck
in the same way as dontUseNinjaBuild and dontUseNinjaInstall). Tests
are only run when "ninja test" exists.
- Error in build phase when build.ninja is missing. We don’t have a
way to fall back to other build methods, so it’s best to be very
clear when we aren’t able to build with ninja
- Set -l flag to 1 when enableParallelBuilding is disabled
Changes added in 4d1fd3775d break
automated updates by moving to a custom version scheme.
This switches back to upstream versioning, while maintaining version
schema convention of `builtins.parseDrvName`.
See issue #43717
xboxdrv doesn’t use scons for installing, but instead using a
makefile! Everything else is in scons so we have to keep that. I’ve
added a dontUseSconsInstall flag to the scons setup-hook to skip the
automatic overwrite of default “make install” call.
The scons build system is python-based and has a binary named scons. Unlike CMake, it cannot generate makefiles so we end up having to override the build, install, and check phases. I have added the setupHook to the scons package so that integration requires no unique steps - just putting scons in nativeBuildInputs should be enough. sconsFlags controls the flags specifically passed to scons while buildFlags, installFlags, and checkFlags should still be usable. Some packages use different names for the prefix flag. In those cases you will have to set "prefixKey" to something like "PREFIX=" as there are multiple names for the "prefix" used in scons.
The waf build system is python-based and hosted locally in each package in the executable file named "waf". Unlike CMake, it cannot generate makefiles so we end up having to override the configure, build, and install phases. I've tried to keep these as close to what's in setup.sh as possible. If there is no waf file in the root directory, then we just copy the one hosted in Nixpkgs. Otherwise the only thing you have to add to a package using Waf is "wafHook" into nativeBuildInputs. wafFlags controls the flags specifically passed to waf while configureFlags, buildFlags, and installFlags are still used as in the generic builder.
Bazel supports per-workspace bootstrap scripts at $WORKSPACE_ROOT/
tools/bazel. This adds support for this behavior, which is needed
by many Bazel projects (OSS and private).
For Git to work properly, I used fetchgit with leaveDotGit. This seems
to be causing hash to change on different systems in different times.
I've replaced generation of last_commit_position.h in tools/gen.py with
just plain nix template. "gn --version" will loose a bit (just commit
hash, without commit height in front of it), but I hope noone relies on
it.
This also updates the bootstrap tool builder to LLVM 5, but not the ones
we actually use for bootstrap. I'll make that change in a subsequent commit
so as to provide traceable provenance of the bootstrap tools.
