Meson now comes with its own set of commands for building, testing,
installing etc., that by default wrap around Ninja. The reason to
prefer using the Meson commands is that they take additional
options (e.g. setting custom timeouts for tests — my motivation for
this change).
Here, I've modified the Meson setup hook so that Meson's test and
install commands will be used instead of Ninja's when Meson's
configurePhase is used. This restriction is to avoid starting to run
Meson directly when dealing with custom build systems that wrap around
Meson, like QEMU's. We don't use meson's compile command, as it just
runs ninja, and that's handled fine by the existing Ninja setup hook.
Naturally the Meson commands don't support entirely the same set of
options that the Ninja ones did, but I checked through Nixpkgs to find
any packages using Meson that used any options that wouldn't be picked
up by this new system. I only found one, and it was just setting
checkTarget = "test", which is the default value for Ninja and has no
Meson equivalent (because we directly tell Meson to run the tests
rather than going through a generic job system like Ninja).
Link: https://github.com/NixOS/nixpkgs/issues/113829
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
Notably fwupd, pipewire and flatpak.
I want to focus on GNOME and other packages I still actually use.
Pipewire is still important but I have not touched the packaging in a while.
The primary motivating example is openssl:
Before the change full package build took 1m54s minutes.
After the change full package build takes 59s.
About a 2x speedup.
The difference is visible because openssl builds hundreds of manpages
spawning a perl process per manual in `install` phase. Such a workload
is very easy to parallelize.
Another example would be `autotools`+`libtool` based build system where
install step requires relinking. The more binaries there are to relink
the more gain it will be to do it in parallel.
The change enables parallel installs by default only for buiilds that
already have parallel builds enabled. There is a high chance those build
systems already handle parallelism well but some packages will fail.
Consistently propagated the enableParallelBuilding to:
- cmake (enabled by default, similar to builds)
- ninja (set parallelism explicitly, don't rely on default)
- bmake (enable when requested)
- scons (enable when requested)
- meson (set parallelism explicitly, don't rely on default)
- waf (set parallelism explicitly, don't rely on default)
- qmake-4/5/6 (enable by default, similar to builds)
- xorg (always enable, similar to builds)
checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
https://gitlab.gnome.org/GNOME/glib/-/compare/2.74.0...2.74.1
- Docs no longer can be generated in static builds.
- Drop merged patches.
- Add a comment to an undocumented patch.
- Drop huge with statement.
- Drop meson override not needed since a4a300dfff
Changelog-Reviewed-By: Jan Tojnar <jtojnar@gmail.com>
Fix the following warning in Meson 0.64:
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
Introduced in 3c7ab542c0
meson did not use these
therefore some packages had to do things
like this
```
substituteInPlace meson.build --replace \
"find_program('nm')" \
"find_program('${stdenv.cc.targetPrefix}nm')"
```
Fixes a traceback where you get the following error:
- AttributeError: 'NoneType' object has no attribute 'get_command'
This happened when cross-compiling e.g. harfbuzz.
A very ugly decision: in order to register the diff between 0.57 and 0.60
releases of Meson in Nixpkgs, I copied the whole directory before actually write
it by hand.
Meson is a delicate package. It needs some patches to properly work in Nixpkgs
and many packages have it as a dependency, from many small applications to
systemd (yay, mass rebuilds in sight!). Updating it is not a trivial and
harmless task.
Therefore, I took the paranoid way and encapsulate the current version in a
subdir, instead of the regular write-over procedure. This way, at the best we
can just remove the whole dir in the future, and at the worse we just maintain
duplicated code.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
