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.
There are several tarballs (such as the `rust-lang/rust`-source) with a
`Cargo.toml` at root and several sub-packages (with their own Cargo.toml)
without using workspaces[1].
In such a case it's needed to move into a subdir to only build the
specified sub-package (e.g. `rustfmt` or `rsl`), however the artifacts
are at `/target` in the root-dir of the build environment. This breaks
the build since `buildRustPackage` searches for executables in `target`
(which is at the build-env's root) at the end of the `buildPhase`.
With the optional `buildAndTestSubdir`-argument, the builder moves into
the specified subdir using `pushd`/`popd` during `buildPhase` and
`checkPhase`.
Also moved the logic to find executables and libs to the end of the `buildPhase`
from a custom `postBuild`-hook to fix packages with custom `build`/`install`-procedures
such as `uutils-coreutils`.
[1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
I thought about doing a seperate output for these, but they're tiny
compared to the size of the binary, so there's no point.
(cherry picked from commit 0489c1b4b20d13fa04e6460ead73893889ff2529)
Cargo uses git-rs which is made to be built against the bundled libgit2
version that hasn't been part of a stable release yet. Using our libgit2
instead of the master version fails during runtime as they are not
compatible anymore.
After the next libgit2 update we can try again but it is likely that
there will also be yet another cargo release at that point in time…
The biggest benefit is that we no longer have to update the registry
package. This means that just about any cargo package can be built by
nix. No longer does `cargo update` need to be feared because it will
update to packages newer then what is available in nixpkgs.
Instead of fetching the cargo registry this bundles all the source code
into a "vendor/" folder.
This also uses the new --frozen and --locked flags which is nice.
Currently cargo-vendor only provides binaries for Linux and
macOS 64-bit. This can be solved by building it for the other
architectures and uploading it somewhere (like the NixOS cache).
This also has the downside that it requires a change to everyone's deps
hash. And if the old one is used because it was cached it will fail to
build as it will attempt to use the old version. For this reason the
attribute has been renamed to `cargoSha256`.
Authors:
* Kevin Cox <kevincox@kevincox.ca>
* Jörg Thalheim <Mic92@users.noreply.github.com>
* zimbatm <zimbatm@zimbatm.com>
simplify the boostrap hashes a bit
build with bundled llvm:
the rust project has forked the llvm compiler to solve some
issues.
With pkgs.llvm the test suite fails.
See https://github.com/rust-lang/rust/pull/43026
And PR #30088
Since cargo build became a rust package, postInstall hook was no longer
called. When the hook was reenabled in
cdd11368426380db545cad84c76e350e5e201adc, it revealed that scripts
leftover from the component based installer are no longer present.
