I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
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 :)
- OpenSSL is evidentally an optional dep. I guess pkg-config found it
before because it was a transitive dep?
- `zstd` and cross-built CMake can get by with a `cmakeMinimal that we
use during bootstrapping, so let's restrict to that.
pkg-config now has a target-sensative wrapper. We shouldn't rebuild
CMake because that wrapper changes. The setup hook should also be a
build time dep.
Fix#99325
Additional changes:
* Change platforms from linux to unix. redo-sh should run as long as
stdenv.shell is a bourne shell.
* Explicitly pass coreutils as a dependency so it can be overriden to
use, say busybox.
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.
Meson allows projects to set `build_rpath` property, containing paths
that will be added during build but will be removed when installing.
When Meson removes build_rpath from `DT_RUNPATH` entry, it just writes
the shorter ␀-terminated new rpath over the old one to reduce
the risk of potentially breaking the ELF files
(when the linker does string de-duplication or something).
But this can cause much bigger problem for Nix, as it can produce
cut-in-half-by-␀ store path references.
For example, in systemd’s libudev, it was removing three `$ORIGIN`-relative paths from
$ORIGIN/../libsystemd:$ORIGIN/../basic:$ORIGIN/../shared:…␀
resulting in the following `DT_RUNPATH` entry:
…␀store/v589pqjhvxrj73g3r0xb41yr84z5pwb7-gcc-9.3.0-lib/lib␀
We previously handled this in `fix-rpath.patch` but the method we prevent
Meson from removing paths added to rpath through `NIX_LDFLAGS` was changed
during 0.55.0 update and I forgot about this second purpose of the patch.
Let’s re-add this clearing code, as it worked without issues for a long time.
Meson allows projects to set `build_rpath` property, containing paths
that will be added during build but will be removed when installing.
When Meson removes build_rpath from `DT_RUNPATH` entry, it just writes
the shorter ␀-terminated new rpath over the old one to reduce
the risk of potentially breaking the ELF files
(when the linker does string de-duplication or something).
But this can cause much bigger problem for Nix, as it can produce
cut-in-half-by-␀ store path references.
For example, in systemd’s libudev, it was removing three `$ORIGIN`-relative paths from
$ORIGIN/../libsystemd:$ORIGIN/../basic:$ORIGIN/../shared:…␀
resulting in the following `DT_RUNPATH` entry:
…␀store/v589pqjhvxrj73g3r0xb41yr84z5pwb7-gcc-9.3.0-lib/lib␀
We previously handled this in `fix-rpath.patch` but the method we prevent
Meson from removing paths added to rpath through `NIX_LDFLAGS` was changed
during 0.55.0 update and I forgot about this second purpose of the patch.
Let’s re-add this clearing code, as it worked without issues for a long time.
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.
The docdir flag needs to include `PROJECT_NAME` according to [GNU guidelines]. We are passing
`-DCMAKE_INSTALL_DOCDIR=${!outputDoc}/share/doc/${shareDocName}` but `$shareDocName` was unset.
The `multiple-outputs.sh` setup hook actually only defines `shareDocName` as a local variable
so it was not available for cmake setup hook. Making it global would be of limited usability,
since it primarily tries to extract the project name from configure script.
Additionally, it would not be set because the setup hook defines `setOutputFlags=`,
preventing the function defining `shareDocName` from running. And lastly, the function
would not run for single-output derivations.
Previously, we tried [not disabling `setOutputFlags`] and passing the directory flags
only for multi-output derivations that do not disable `setOutputFlags` but that meant having
two different branches of code, making it harder to check correctness. The multi-output
one did in fact not work due to aforementioned undefined `shareDocName`. It also broke
derivations that set `setOutputFlags=` like [`qtModule` function does] (probably
because some Qt modules have configure scripts incompatible with `configureFlags` defined
by `multiple-outputs.sh` setup hook). For that reason, it was [reverted], putting us back to start.
Let’s try to extract the project name from CMake in the cmake setup hook.
CMake has a `-L` flag for dumping variables but `PROJECT_NAME` did not seem to be among them
when I tested, so I had to resort to parsing the `CMakeLists.txt` file.
The extraction function is limited, it does not deal with
* project name on different line from the `project(` command opening
- that will just not get matched so we will fall back to
using the derivation name
* variable interpolation
- we will just fall back to using derivation name when the extracted
`project_name` contains a dollar character
* multiple [`project`] commands
- The command sets `PROJECT_NAME` variable anew with each call, so the
last `project` call before `include(GNUInstallDirs)` command will be used
when the included module would [cache the `CMAKE_INSTALL_DOCDIR` variable].
We will just take the first discovered `project` command for simplicity.
Hopefully, there are not many projects that use multiple `project` calls
before including `GNUInstallDirs`.
In either case, we will have some subdirectory so the conflicts will be minimized.
[GNU guidelines]: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#index-docdir
[not disabling `setOutputFlags`]: be1b22538a
[`qtModule` function does]: https://github.com/NixOS/nixpkgs/pull/12740
[reverted]: https://github.com/NixOS/nixpkgs/pull/92298
[`PROJECT_NAME`]: https://cmake.org/cmake/help/v3.18/variable/PROJECT_NAME.html
[`project`]: https://cmake.org/cmake/help/v3.18/command/project.html
[cache the `CMAKE_INSTALL_DOCDIR` variable]: 92e30d576d/Modules/GNUInstallDirs.cmake (L298-L299)
This reverts commit be1b22538a.
The commit broke Qt modules using CMake because they disable setOutputFlags.
There is no need to have these flags limited to multiple output derivations since it
should just work. If it does not, it is a bug that should be fixed as per
https://github.com/jtojnar/cmake-snips#assuming-cmake_install_dir-is-relative-path
Likewise, having a variable to disable passing the flags is also unnecessary,
since CMake, unlike some configure scripts, ignores unknown flags. And if a person
does not like the values, they can just override them by passing the offending
flag with a different value to cmakeFlags.
This brings cmake inline with the behaviour used for configure
scripts, defined in multiple-outputs.sh. It's important because
that setup hook will only set shareDocName if multiple outputs are in
use (and setOutputFlags hasn't been disabled). So previously,
CMAKE_INSTALL_DOCDIR would be set to $out/share/doc for single-output
derivations, instead of $out/share/doc/$shareDocName, which would
result in collisions.
Since this hook now uses the setOutputFlags variable, I had to remove
the empty assignment of it added in
a714284d8b.
Fixes: https://github.com/NixOS/nixpkgs/issues/82304
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
flat hashes can be substituted through hashed-mirrors, while recursive
hashes can’t. This is especially important for Bazel since the bazel
fetch dependencies can come from multiple different methods (git,
http, ftp, etc.). To do this, we create tar archives from the
output/external directory, which is then extracted to build. All of
the Bazel hashes are all updated.
@the-kenny did a good job in the past and is set as maintainer in many package,
however since 2017-2018 he stopped contributing. To create less confusion
in pull requests when people try to request his feedback, I removed him as
maintainer from all packages.
The nss update is needed for security update of firefox.
For linux platforms only about 1k aarch64 rebuilds are missing;
the diff on Hydra looks OK. Darwin needs 20k more rebuilds,
but I don't think we want to wait for that.
The old `CC=.. CXX= .. meson ...` env var hack I removed in
3c00ca03a2 had a side effect of ensuring
that Meson always had access to a native C compiler, which unforunately
it expects in most cases. Thankfully, that will be fixed soon.
The cross file is added in the `mkDerivation`. It isn't nice putting
build tool-specific stuff here, but our current architecture gives us
little alternative.
See comment in code and the PR it references,
https://github.com/mesonbuild/meson/pull/6827, for details.
We can remove entries from the cross file because they will be gotten
from env vars now.
