| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The reason is that we can not expect the extended logic run on git
dependencies starting from Cargo 1.68 to be reproducible in future
versions, and thus the output hash would not be sufficiently stable.
https://github.com/rust-lang/cargo/pull/11414
|
|
fixes build when git dependencies contain symlinks into parent directory
needed for libdeltachat
|
|
is used
|
|
Since we grep for 'workspace', it's possible the script ends up running
on a Cargo.toml that has the word 'workspace' in a comment, but does not
actually use workspaces
|
|
|
|
workspace inheritance
Rust 1.64.0 added support for workspace inheritance, which allows
for crates to inherit values such as dependency version constraints or
package metadata information from their workspaces [0].
This works by having workspace members specify a value as a table, with
`workspace` set to true. Thus, supporting this in importCargoLock is as
simple as walking the crate's Cargo.toml, replacing inherited values
with their workspace counterpart.
This is also what a forthcoming Cargo release will do for `cargo vendor` [1],
but we can get ahead of it ;)
[0]: https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#cargo-improvements-workspace-inheritance-and-multi-target-builds
[1]: https://github.com/rust-lang/cargo/pull/11414
|
|
|
|
Conflicts:
- pkgs/development/python-modules/imageio/default.nix
- pkgs/development/python-modules/pytest-order/default.nix
|
|
|
|
Sometimes it's more ergonomic to set up the build environment in
hooks, to add to the default behaviour rather than replacing it. It's
very surprising that the fetcher works fine with a custom unpackPhase,
but not with custom preUnpack or postUnpack.
Packages that use preUnpack or postUnpack and Cargo FODs seem to be
very rare. I searched Nixpkgs for files containing one of
"cargoHash", "cargoDeps", and "cargoSha256", and one of "preUnpack" or
"postUnpack", and only found two such packages:
python3.pkgs.tokenizers and rustdesk. Neither of their Cargo FOD
hashes are affected by this change. So if that's any indication,
we're unlikely to be breaking many out-of-tree hashes with these
changes either.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes linker errors while building build.rs where it tries to link libiconv but cannot find it.
Rust executable build for Darwin need libiconv, and indeed buildInputs already has this case handled.
So why is another change needed? Suppose we are cross compiling from Darwin (the build platform) to something else, and the package has a build.rs build script.
The build script is built for the build platform (Darwin) and is also a regular Rust executable, needing libiconv, but due to cross compilation (and strict deps) we need an extra nativeBuildInput.
|
|
|
|
rust, firefox, spidermonkey: cleanup
|
|
`cargoDeps` is already passed as `mkDerivation` arguments, and should
not be `passthru`ed again. This fixes the mismatch of `drv.cargoDeps`
and the actual dependency when the original derivation is overriden.
|
|
This commit reverts #209113, since aarch64-linux now uses GCC 12 by default.
|
|
unpackFile doesn't dereference symlinks if cargoDeps is a directory, and
some cargo builds run into permission issues because the files the
symlinks point to are not writable.
|
|
|
|
This is to make it possible to implement support for updating
`Cargo.lock`s in nix-update by exposing the path to the `Cargo.lock`
file
|
|
v1 lock files (generated by default by Cargo versions 1.40 and below)
use a single table, `metadata`, to store the checksums of packages.
The primary motivation for doing this now is that we're considering
vendoring all Cargo lock files in Nixpkgs, some packages still use it
(e.g. cargo-asm), and adding support for it doesn't increase the
complexity of the function. No matter the outcome of the vendoring
discussion, this is a nice thing to have because Cargo still supports v1
lock files.
|
|
|
|
Used in cases where you need to get the vendor of a target. Such as when
you need to perform dependency resolution outside of Cargo (eg in
Kolloch's crate2nix).
|
|
|
|
Currently cargo-setup-hook instructs the builder upon cargoSha256 or
cargoHash being out-of-date compared to the Cargo.lock file.
The instructions can be simplified a bit, because nowadays it is fine to
keep a hash empty, instead of filling it with
`0000000000000000000000000000000000000000000000000000`.
Nix nowadays outputs SRI hashes, which should usually be placed in
`cargoHash` instead of `cargoSha256`, but the instructions are still
only referring to `cargoSha256`.
Lastly, the output of Nix doesn't include `got: sha256: ` anymore, as it
now outputs `got: sha256-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=`.
It would be nice to make it clear that the trailing `=` is important as
well, so the full example SRI hash is mentioned.
|
|
|
|
|
|
|
|
This reverts commit 46ee37ca1d9cd3bb18633b4104ef21d9035aac89, as it breaks
anything that uses libcxx on Darwin, as well as cross-compilation to at
least armv6l.
As there's no clear solution at this time, reverting it is the best
option, as this only reduces build time closure size (something we can
arguably live with).
https://github.com/NixOS/nixpkgs/pull/207352#issuecomment-1418363441
https://github.com/NixOS/nixpkgs/pull/207352#issuecomment-1420124250
|
|
|
|
not needed here, set by fetchCargoTarball
|
|
As proposed in https://github.com/NixOS/nixpkgs/pull/82496, we should only set the related env vars for the fetcher instead of breaking the function of cargo itself.
|
|
This commit corrects the value of `CARGO_CFG_TARGET_POINTER_WIDTH`
for ILP32 machines like the Apple Watch and mips64n32.
|
|
|
|
Fixes #204051. I have tried this on the reproducer stated in the ticket.
```
[nix-develop]$ $(nix-build -I nixpkgs=/home/shana/programming/nixpkgs --no-out-link)/tests/foo
running 1 test
test check_module_name ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change switches to using GCC 11 by default on aarch64-linux, as well as passing `-lgcc` to the linker, per #201485.
See #201254 and #208412 for wider context on the issue.
|
