Repository navigation
Set a target for build scripts' products #5457
Description
Activity
This would be useful for library integration tests as well. For example -- building a plugin library and having an external (non-rust) program load the library for testing.
This would be useful for debcargo as well, we're having the same issue with ripgrep.
cargo's documentation says build scripts should modify anything not in
OUT_DIRso settingCARGO_TARGET_DIR(and presumably having the build.rs write to it) would contract that. What I'd suggest instead is to allow one to query what theOUT_DIRshould be for a given package.Currently what we're doing in Debian is running this ugly shell snippet (taken from ripgrep's own scripts) right after we run
CARGO_TARGET_DIR=target cargo install:ln -sf "$$(find "target/$(DEB_HOST_RUST_TYPE)/release" -name ripgrep-stamp -print0 | xargs -0 ls -t | head -n1 | xargs dirname)" cargo_out_dirThen the rest of the Debian packaging can find the outputs in the static location
cargo_out_dir.Note that unfortunately the above does not generalise, since "ripgrep-stamp" is a file specifically created by ripgrep's build.rs
This would be useful and is really needed in my opinion. Build scripts must have configurable output the same way cargo does. I have to parse the target dir out of the out dir just to figure out where to put the result. My particular reason is integration in autotools project where VPATH builds must work. It would also help to have something like
cargo build --manifest-dir=..., but that's not the point of this issue.
@infinity0: I haven't found anything like that in the documentation and there are use cases for build scripts touching stuff outside out dir. Code generation, metadata generation, (c)bindgen output, and so on.- added a commit that references this issue
on Sep 4, 2019 Another use-case where I would have liked to take advantage of this: Generated header files for FFI. I would find it preferable to output files like so:
|- target/debug/ |--- my_ffi_lib.a |--- my_ffi_lib.so |--- my_ffi_lib.dll |--- include/ |------ my_ffi_lib.h [Generated by cbindgen]This makes it easier to package my binaries + includes.
Reacted by Kornel, Philipp Gesang, Stanislav Tkach, Martin Papanek, alexlapa, Be, bl-ue and Daniel Wyatt- changed the title
[-]Set CARGO_TARGET_DIR for build scripts[/-][+]Set a target for build scripts' products[/+]on Sep 17, 2019 This overlaps with post-build tasks, so I'm closing this in favor of #545
Reacted by Ralph MinderhoudPost-build tasks are in "RFC hell", so I'm reopening this. This is a simpler change that can be done without depending on addition of a major new feature in Cargo. Also there's a related RFC that calls for an artifacts output dir.
We only ask build.rs not to write into src so that src reaches some fixed point, right? We could therefore write to files in src provided code doing the writing knows upon what src files particular src files depend.
There are several tricks for doing this, like providing additional binary build targets which you invoke using
cargo run --binfrom a Makefile or using cargo-make, or maybe even build.rs comparing file modification times.fn file_creation(path: AsRef<Path>) -> SystemTime { metadata(path: ).created().unwrap() }We could simplify adding lightweight build targets I think, maybe
cargo prebuild foowould run only#[prebuild] fn foo.., similarly howcargo test fooruns only#[test] fn foo...- added a commit that references this issue
on Oct 20, 2022
From tmccombs:
Cargo exports an “OUT_DIR” environment variable to build scripts so that build scripts can store outputs there. And for generated source code this is fine. However when generating final artifacts that should be distributed with the binary, such as documentation (man pages) or shell completion scripts, storing them in the OUT_DIR is somewhat problematic. Not only is OUT_DIR different per package, but the path has some kind of hash in it, and isn’t included in the output of cargo metadata. Which makes such artifacts difficult to discover with tools like cargo-deb or to write robust packaging scripts.
As a specific example, ripgrep uses clap to generate shell completion scripts, which it stores in the OUT_DIR, and the maintainer uses cargo-deb to produce debian packages. However, the resulting debs don’t contain the completion scripts. cargo-deb has a way to specify additional assets by path to include, but since the OUT_DIR isn’t fixed, it isn’t possible to specify a fixed path for the completion scripts.
Currently
CARGO_TARGET_DIRis read by Cargo. It would be useful if Cargo also set it (if not set already) to the actual value it uses.It doesn't have to be literally
CARGO_TARGET_DIRenv variable, it could also be a directive that tells Cargo to place a file there, or anotherOUT_DIR-like directory for more permanent products.