Set a target for build scripts' products

[kornelski]

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_DIR is 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_DIR env variable, it could also be a directive that tells Cargo to place a file there, or another OUT_DIR-like directory for more permanent products.

[inferiorhumanorgans]

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.

[infinity0]

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_DIR so setting CARGO_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 the OUT_DIR should 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_dir

Then the rest of the Debian packaging can find the outputs in the static location cargo_out_dir.

[infinity0]

Note that unfortunately the above does not generalise, since "ripgrep-stamp" is a file specifically created by ripgrep's build.rs

[nertpinx]

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.

[cbeck88]

I ran into this today... I opened a one-line PR to address this: #7325 curious what devs think

[rminderhoud]

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.

[kornelski]

Forum discussion.

This overlaps with post-build tasks, so I'm closing this in favor of #545

[kornelski]

Post-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.

[burdges]

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 --bin from 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 foo would run only #[prebuild] fn foo.., similarly how cargo test foo runs only #[test] fn foo...

[Be-ing]

This overlaps with #545, so I'm closing this in favor of #545

I don't think this is the same as post-build tasks. Rather, I think this is a prerequisite for many post-build tasks to be useful.

[epage]

This has very strong overlap with #9661 and that issue has a bit more discussion, so I'm going to close in favor of that.