A CMake based C++ project (taskwarrior
) that has a certain Rust written component, is using a Rust crate named cxx
, and requires an executable named cxxbridge
that is provided by the crate cxxbridge-cmd
. All of the required crates should be available in the project’s Cargo.lock
file and hence the source code of the crate that can build the executable cxxbridge
is available in the cargoDeps
of the main project.
The problem is that one of the CMakeLists.txt
files used by the project lookup for a cxxbridge-cmd
in $PATH
and if that is failed they try to simply cargo install
it. From some reason the cargo install
command isn’t aware of the available cargoDeps
and tries to download the cargo deps from the internet (and fails of course).
I don’t want to use the cxx-rs
Nix package which provides the cxxbridge
command, because upstream doesn’t recommend using a cxxbridge-cmd
crate that potentially has a potentially different version from the cxx
macros that are used in the main project (taskwarrior
). See:
opened 10:37AM - 29 Nov 24 UTC
closed 06:13AM - 01 Dec 24 UTC
Hello,
TL;DR: I want to build packages that depend on `cxx` macros with a `cx… xbridge` executable that might be of different version. Is that safe? Is it possible you'd be able to guarantee e.g that any `cxxbridge` version `1.0.x` is compatible with any `cxx` macro `1.0.y`?
#### Details:
I don't use crate directly, and I don't know how to write Rust. I am simply a distributor of the [`taskwarrior`](https://github.com/GothenburgBitFactory/taskwarrior) package on NixOS. `taskwarrior` is using [corrosion](https://github.com/corrosion-rs/corrosion), which uses `cxxbridge` and `cxx` macros (perhaps `taskwarrior` uses `cxx` macros directly as well).
Nix's build system has this ~~bug~~ feature that we disallow network usage during builds. All code from the internet has to prove that it can be fetched from the internet in a reproducible manner (we use hashes for that), and after all code is fetched, we "close" the internet connection and try to build our packages.
[corrosion](https://github.com/corrosion-rs/corrosion) uses `cxxbridge` and `cxx` macros and distributes a cmake file that checks that `cxxbridge --version` is the same version as in the `Cargo.lock` of the built project (in this case, `taskwarrior`). The problem we experience is that `taskwarrior` uses a certain version of `cxx` in their `Cargo.lock` file, and if these versions are not matched, the corrosion cmake rules tries to fetch the correct `cxxbridge` from the internet via a plain `cargo install cxx` command.
Our distribution does provide a `cxxbridge` executable that is checked in `$PATH` by corrosion before spawning the (failing without internet) `cargo install cxx` command. But, the problem is that it is very hard for use distributors to make sure these 2 versions are the same - the version of the distributed `cxx-rs` Nix package which provides the `cxxbridge` executable, and the `cxx` version in `taskwarrior`'s `Cargo.lock` file.
I asked `corrosion` to perhaps loose their version check of the `cxx` version from the built project's `Cargo.lock` file and the `cxxbridge --version`, but they don't want to assume any such compatibility is guaranteed. Hence I ask the question above :).
Best,
Is there a way to tell any cargo
command to find the crates where the cargoSetupHook
puts them? Current attempt is at:
NixOS:master
← doronbehar:pkg/taskwarrior3
opened 04:48PM - 28 Nov 24 UTC
## Description of changes
## Things done
- Built on platform(s)
- [x] x86_6… 4-linux
- [ ] aarch64-linux
- [ ] x86_64-darwin
- [ ] aarch64-darwin
- For non-Linux: Is sandboxing enabled in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
- [ ] Tested, as applicable:
- [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- and/or [package tests](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests)
- or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
- made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
- [x] Tested basic functionality of all binary files (usually in `./result/bin/`)
- [24.11 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md) (or backporting [23.11](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) and [24.05](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2405.section.md) Release notes)
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
- [ ] (Module updates) Added a release notes entry if the change is significant
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module
- [x] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
---
Add a :+1: [reaction] to [pull requests you find important].
[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
[pull requests you find important]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc
Strategy I’ve employed before is to use multiple derivations when building things across multiple languages, would that work here? (Of course it makes overriding a bit harder.)
That sounds not bad. If you have an idea how to employ the cargoDeps
derivation and build one of the crates from there, that would be very helpful.
The solution was pretty simple!
postUnpack = ''
export CARGO_HOME=$PWD/.cargo
'';
2 Likes