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`]: https://github.com/NixOS/nixpkgs/commit/be1b22538a60e52987d238bb11f93043682b6e9a
[`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]: https://github.com/Kitware/CMake/blob/92e30d576d66ac05254bba0f0ff7d655947beb0f/Modules/GNUInstallDirs.cmake#L298-L299
Michael Weiss