-
-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add compile mode for cargo check #107
Comments
This task could be made easier with #118, given that Note that the |
I think this feature would require a sizeable refactor of AFAIK, we can't wrap |
I ran the Aside, since rust check doesn't need to link or emit binary, is it even benefiting from cargo2nix's native deps? I would like to constrain the role so that cargo2nix is doing maximum utility but with only strictly necessary second-system overhead |
@psionic-k It depends on the particular crate. If a crate provides a |
See reasoning in #92 for not blocking, but also not pursuing more support for non-output Nix derivations |
As mentioned in #92 (comment), we should add an option for
compileMode = "check"
, which would correspond tocargo check
. This would be useful for supporting other tools like Clippy in Nix expressions run in CI environments, for example.To find what artifacts should be copied to the Nix store in a
cargo check
compile mode, we first generate a new crate withcargo new --bin foo
and then check the contents of thetarget
directory after each command (with acargo clean
in between each run).cargo check
cargo check --release
From this, it seems that the
.d
and.rmeta
artifacts are of the most importance and should definitely be copied into the Nix store. Runningcargo clippy
andcargo clippy --release
also produced identical results, which confirms that bothcheck
andclippy
share the same cache and that the latter doesn't produce any additional artifacts.The real question is how to expose the artifacts from the Nix store into the current build. For all other compile modes, we achieve this using a
rustc
wrapper which silently forwards vendored artifacts from the Nix store to the compiler. However, these artifacts aren'trlib
s, so I assume this wrapper won't be able to help us here.CC @trha, do you have any ideas?
Brief diversion about rmeta artifacts
According to this comment on
rust-lang/cargo
, it seems that bothcargo build
andcargo check
produce.rmeta
artifacts, but each contains slightly different data and aren't interchangeable at the time of writing.We currently don't retain these
.rmeta
artifacts in derivations built withcompileMode = "build"
incargo2nix
. Crates seem to compile perfectly fine without them, so presumably eithercargo
orrustc
is generating them on the fly if it has access to the source directory. Should we keep these.rmeta
files incompileMode = "build"
as well? It would seem a bit inconsistent for us to retain them incheck
mode but not inbuild
mode.The text was updated successfully, but these errors were encountered: