Add support for test build scripts

[erickt]

Testing code generation projects like quasi is a little difficult because I would like to use quasi to generate some test files, but I can't since the build scripts are compiled before the main project. As a work around I can add a test crate that depends on quasi, but it would be more convenient if the quasi Cargo.toml file had a test-build script that can depend on the current project and gets run before the tests.

[pnkfelix]

Indeed, I was expecting to be able to put a demonstration of code-generation tool by putting a cargo project into the examples/ directory of the codegen tool, and naively assumed that cargo test would build the example.

[alexcrichton]

I think that using build scripts for code generation is relatively common, and this seems like a pretty clear-cut thing that can be added! From a high-level design perspective, there's two possible routes I think we could take:

1. Invoke current build scripts with a different set of arguments.
2. Add a new dev-build entry to the manifest which is used whenever dev-dependencies are used as well.

I think (1) should be avoided because it'd probably break many existing build scripts (which aren't expected to run twice) and it also doesn't allow for dev-build-specific dependencies. Using (2) allows existing build scripts to be backwards compatible as well as adding a new dev-build-dependencies section to the manifest for those only used by the dev-build script.

This is a pretty meaty project, however, and it skirts the line of "this requires an RFC", but I'd be willing to help anyone who wishes to implement!

[alexcrichton]

Also cc #1430 (build scripts for just binaries) and #1162 which may start being required for this to become usable.

[alobb]

I'd be interested in taking a look at this, but don't have any idea where to start.

[alexcrichton]

@alobb I think that we've pushed Cargo enough to its limits recently that given issues like this, #1430, and #1982 we may wish to explore an RFC in this space before tackling this issue specifically.

[carols10cents]

Closing since this needs an RFC.

[dcsommer]

My project has the following constraints:

• Library code does not depend on C++ symbols
• Tests for the library do depend on C++ symbols and crate-private functions (so a separate crate for tests is no good)

I was able to workaround this issue using the 1.63 release in stable Rust by doing:

• Separate crate cpp-linker that has
  • An empty lib.rs
  • build.rs links the C++ code using println!("cargo:rustc-link-lib=static:-bundle={}", lib_name); (I also use the [+-]whole-archive linking modifier, but that's not relevant to this). -bundle was stabilized in 1.63 and allows an rlib crate to defer the linking of C++ symbols until final test binary linking.
• Library rlib crate mylib
  • Has [dev-dependency] on cpp-linker
  • Include extern crate cpp_linker; inside of mod tests to bring in the C symbols

That's it! No more separate test crate needed. cpp-linker can be reused by many other libraries' tests.