When dontUseCmakeBuildDir is true (aka the default), it overrides
cmakeDir regardless of the package configuration.
While packaging netbee, I needed to both keep dontUseCmakeBuildDir to
true (some hardcoded paths expect the build folder) and set cmakeDir
(since CMakeList.txt was in a subfolder) which proved impossible.
Here is the fix.
Lots of packages are missing versions in their name. This adds them
where appropriate. These were found with this command:
$ nix-env -qa -f. | grep -v '\-[0-9A-Za-z.-_+]*$' | grep -v '^hook$'
See issue #41007.
The hack of using `crossConfig` to enforce stricter handling of
dependencies is replaced with a dedicated `strictDeps` for that purpose.
(Experience has shown that my punning was a terrible idea that made more
difficult and embarrising to teach teach.)
Now that is is clear, a few packages now use `strictDeps`, to fix
various bugs:
- bintools-wrapper and cc-wrapper
On GNU/Linux the build references these files, so let's fetch them from
the Chromium repository. I haven't checked whether they are heavily
patched or whether we can use the version from LLVM, but when looking at
the changes, they do seem to divert a bit from upstream LLVM.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @matthewbauer, @stesie
The tarball from upstream seems to be generated on the fly, so the
output is not deterministic and using fetchzip makes this more reliable
as we have a recursively hashed output path without any of the
non-determinisms in tarballs.
Unfortunately, the build still fails on NixOS systems, because we need a
few more stuff in the build tree.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @matthewbauer, @stesie
This has already been patched against gnumake4 (519f0b8db2)
but we still have packages depending on gnumake3, so let's also apply
the same patch to gnumake 3.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @shlevy, @vcunat
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/doit/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/.doit-wrapped --help` got 0 exit code
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/.doit-wrapped help` got 0 exit code
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/.doit-wrapped --version` and found version 0.31.1
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/doit --help` got 0 exit code
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/doit help` got 0 exit code
- ran `/nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1/bin/doit --version` and found version 0.31.1
- found 0.31.1 with grep in /nix/store/xgn48w19lgr8xnijgqcx91389b5hldv2-doit-0.31.1
- directory tree listing: https://gist.github.com/a0ba66d49e0c01c3003ca50e9ad705a0
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 2.0.6 with grep in /nix/store/5rgayqfl64bn9pyrfsc9kcm2c4vdqybi-waf-2.0.6
- found 2.0.6 in filename of file in /nix/store/5rgayqfl64bn9pyrfsc9kcm2c4vdqybi-waf-2.0.6
Upstream insists on not allowing bindir and other dir options
outside of prefix for some reason:
https://github.com/mesonbuild/meson/issues/2561
We remove the check so multiple outputs can work sanely.
In common distributions, RPATH is only needed for internal libraries so
meson removes everything else. With Nix, the locations of libraries
are not as predictable, therefore we need to keep them in the RPATH. [1]
Previously we have just kept the RPATH produced by the linker, patching
meson not to remove it. This deprived us of potentially replacing it
with install_rpath provided by project so we had to re-add it manually,
and also introduced a vulnerability of keeping build paths in RPATH.
This commit restores the clean-up but modifies it so the items starting
with /nix/store are retained.
This should be relatively safe since the store is immutable, however,
there might be some unwanted retainment of build_rpath [2] if it contains
paths from Nix store.
[1]: https://github.com/NixOS/nixpkgs/issues/31222#issuecomment-365811634
[2]: http://mesonbuild.com/Release-notes-for-0-42-0.html#added-build_rpath-keyword-argument
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 1.10.2 with grep in /nix/store/ymhiik4c7604dxzlnvrrzj88d2lkcy16-ant-1.10.2
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/y8nbk5hk9d291bgwi1aag83z01w1l04i-buildbot-worker-1.1.0/bin/.buildbot-worker-wrapped --help` got 0 exit code
- ran `/nix/store/y8nbk5hk9d291bgwi1aag83z01w1l04i-buildbot-worker-1.1.0/bin/.buildbot-worker-wrapped --version` and found version 1.1.0
- ran `/nix/store/y8nbk5hk9d291bgwi1aag83z01w1l04i-buildbot-worker-1.1.0/bin/buildbot-worker --help` got 0 exit code
- ran `/nix/store/y8nbk5hk9d291bgwi1aag83z01w1l04i-buildbot-worker-1.1.0/bin/buildbot-worker --version` and found version 1.1.0
- found 1.1.0 with grep in /nix/store/y8nbk5hk9d291bgwi1aag83z01w1l04i-buildbot-worker-1.1.0
