1b748554d5
This cuts down the dependency tree on some rust builds where a crate not just exposes a binary but also a library. `$out/lib` contained a bunch of extra support files that among other information carry linker flags (including the full path to link-time dependencies). Worst case this led to some binary outputs depending on the full build closure of rust crates. Moving all the `$out/lib` files to `$lib/lib` solves this nicely. `lib` might be a bit weird here as they are most of the time just rlib files (rust libraries). Those are essential only required during compilation but they can also be shared objects (like with traditional C-style packages). Which is why I went with `lib` for the new output. One of the caveats we are running into here is that we do not (always) know ahead of time of a crate produces just a library or just a binary. Cargo allows for some ambiguity regarding whether or not a crate provides one, two, … binaries and libraries as it's outputs. Ideally we would be able to rely on the `crateType` entirely but so far that isn't the case. More work on that area might show how difficult that actually is. |
||
|---|---|---|
| .. | ||
| build-rust-crate | ||
| patch-registry-deps | ||
| cargo-vendor-normalise.py | ||
| carnix.nix | ||
| crates-io.nix | ||
| default-crate-overrides.nix | ||
| default.nix | ||
| fetchcargo-default-config.toml | ||
| fetchcargo.nix | ||
| fetchcrate.nix | ||