Cargo: Specify a build script for only binaries

[alexcrichton]

Right now a build script's output is always linked to a library if it's available (and to a binary if there is no library available). There is a use case, however, where a library doesn't actually use the output but _only_ the binary does. This may be a nice option to have.

[aidanhs]

If I'm reading this correctly, there's a nasty side effect of "and to a binary if there is no library available" - if you have a build script being used for a binary, then touch src/lib.rs, cargo starts ignoring the build script when building the binary!

[aidanhs]

https://github.com/rust-lang/cargo/blob/8a8ea1e89ee8bc/src/cargo/ops/cargo_rustc/mod.rs#L360
Somewhat unforgiving conditional there. I guess I'm not going to be following the advice to have a lib.rs and main.rs.

Fortunately, using other files with mod doesn't break it as well.

[alexcrichton]

That conditional is required to prevent linkage errors in the common case due to duplicate symbols. Cargo assumes that binaries link to the library and as a result if the library already pulls in the native dependencies then the binaries shouldn't as it'd just cause more errors.

[aidanhs]

Ah. You are right and I was doing it wrong.

[posborne]

I ran into this issue today and it threw me for a loop (especially given the difficulty with debugging build scripts to start with). Here's what I attempted (guessing at what might be supported). Obviously, this did not work.

# ...
[[bin]]
name = "foo"
path = "src/foo.rs"
build = "build_foo.rs"

[[test]]
name = "test_baz"
path = "test/test_baz.rs"
build = "test/build_test_baz.rs"

One nice thing with this approach would be that it would be possible to eliminate things like the libc-test crate in favor of just having those contents be in a test binary build script. It would be quite nice to be able to just run cargo test for libs using ctest such as libc (and nix soon).

[breeswish]

This would be a really nice feature. Currently my solution is to split library and binary into different workspaces manually. However it makes the directory structure more complex and dependency management becomes harder. I need to carefully sync these dependency versions specified in Cargo.toml, otherwise it may result in different versions.