Build subcommand or option that builds all targets (including tests)

[bruno-medeiros]

Currently cargo build will build the lib target and the bin targets, but none of the test targets.
cargo test --no-run will build the tests targets (and the lib target), but not the bin targets.

Ideally, there should be a cargo build command or option that would build all the crate's targets. Not just for convenience and (possibly) better performance, but also to be be able to integrate future cargo build options and have them apply to the test targets builds too. For example, using "cargo check" or something similar. (#1313)

[alexcrichton]

Could you expand on the motivation for this? I can't really think of a use case for "build everything" unless you want to actually use everything right afterwards...

[bruno-medeiros]

Well:

• You know your change might break the execution of your tests, but you don't want to run them straight away - because generally speaking, they take a long time to run. So mentally you accept your change might break the tests execution (and that's a problem for later), but you still want to verify now that the tests compile, at the very least.
• You do a change you expect will not break the tests at all (for example, renaming some element). But you do a mistake (perhaps you forgot to rename some reference in the tests) and that change does break the tests compilation. You'd want to be able to check that by just building the whole crate.

These scenarios happen to me very often in Java projects I work with. And with Rust I'm also now using cargo test --no-run as my default crate build method. (Since tests are a lot more code, and they change much more frequently, than bin targets, so I'd rather forsake the bin targets first)

[alexcrichton]

Hm it sounds like cargo test --no-run solves both these cases? Are there parts that command doesn't compile?

[bruno-medeiros]

Hm it sounds like cargo test --no-run solves both these cases? Are there parts that command doesn't compile?

I mentioned above that it doesn't build the bin targets, but upon trying it again, it seems it does, so I guess I was wrong in my understanding. So yeah, it seems like cargo test --no-run builds all tests, that's good.

I'm happy with this, as long as gong forward cargo test --no-run gets the same sub-options that get added to cargo build, for example the ability to output JSON (#1403), or something like cargo check (#1313).

[bruno-medeiros]

After some user reports of cargo test --no-run not working as expected under IDE usage, I've found out what the problem was: it only generates the bin targets if there is a test target (either explicit [[test]] in Cargo.toml or just a tests/blah.rs file) in the crate. Reopening.
(This explains my original misunderstanding of whether cargo test --no-run was building bin targets or not)

[alexcrichton]

Oh interesting! I thought binaries were at least compiled with --test, but are they marked with test = false?

[bruno-medeiros]

They are not marked with test=false, but even if they are, it makes no difference for the problem mentioned above. With test=false, the executable for the implicit test target of the bin target (I don't know a better term) is not generated.
But the executable I complain about not being generated is the executable for the bin targets themselves, the ones running fn main(), not a tests executable.

[bruno-medeiros]

I just realized (in case it wasn't clear), it's not just that the target/*.exe executables are not generated for the bin targets, but none of the compilation and error checking is done. So if there are error in main.rs or so, they are not checked. (again, except it there are tests targets defined...)

[alexcrichton]

Hm so to confirm, the only situation I believe where executables are not compiled are when integration (tests/* or [[test]]) tests are missing. If those exist then the executables should always be compiled.

This choice was done because if integration tests are missing the executables are still compiled with --test by default, meaning they get a chance at all the same normal checks. Additionally it means incremental changes to executables don't need to compile two things on a cargo test.

Does that make sense? Can you confirm that the bad behavior you're seeing only happens in projects with no integration tests?

[bruno-medeiros]

Does that make sense? Can you confirm that the bad behavior you're seeing only happens in projects with no integration tests?

Yes, that's correct. Apparently even a blank .rs file in tests/ works as a workaround, I've been using that in my projects: https://github.com/RustDT/RustLSP/blob/master/tests/dummy.rs

[alexcrichton]

Ah ok, just wanted to make sure! So given that are the executables themselves that different with and without --test? Does --test not compile enough of the executable to validate it?

[bruno-medeiros]

So given that are the executables themselves that different with and without --test? Does --test not compile enough of the executable to validate it?

I don't quite understand. What is --test ? Do you mean if the executables are different between cargo build and cargo test --no-run?

I can't seem to reproduce the situation were the errors are not even checked (if the bin file has errors), so maybe I misunderstood that, or it was fixed in the meanwhile, or something.

But the original problem that the bin executable is not created is still there (with a bin file without source errors). Let me try to summarize the cases. So, on a project with a mybin binary target:

• Running cargo build:
  target/debug/mybin.exe gets created.

• Running cargo test --no-run and having no integrations tests:
  target/debug/mybin.exe does not get created.

• Running cargo test --no-run and having an empty tests/dummy.rs file:
  target/debug/mybin.exe gets created.

[alexcrichton]

Ah by --test I basically mean Cargo executing rustc --test. The behavior you've described I believe is accurate. If you execute cargo test --no-run and you have no integration tests, then target/debug/deps/mybin-xxxxxxx.exe should be created (the unit tests for that executable).

I think I may be a bit lost here at this point, can you restate the original problem perhaps again with all the new information?

[bruno-medeiros]

Sure, let's look at the recap of what currently happens:

For source without errors and a mybin binary target:

• Running cargo test --no-run and having integration tests:
  target/debug/mybin.exe gets created.

• Running cargo test --no-run and having no integrations tests:
  target/debug/mybin.exe does not get created. This case is what I consider to be the problem. It should also create mybin.exe in this case.

[carols10cents]

I believe this was fixed by #4400. Please reopen if I'm incorrect!

[BenjaminGill-Metaswitch]

I'm not convinced this is working as intended (stable Rust 1.21; proprietary code, hence the redacting):

$ cargo clean
$ cargo build --all-targets
<redacted>
   Compiling foo v0.1.0 (file:///<redacted>/foo)
    Finished dev [unoptimized + debuginfo] target(s) in 103.69 secs
$ ll ../../target/debug/
total 39648
drwxr-xr-x. 26 bjg2 unix-domainusers     4096 Oct 13 11:23 build
drwxr-xr-x.  2 bjg2 unix-domainusers    12288 Oct 13 11:25 deps
drwxr-xr-x.  2 bjg2 unix-domainusers        6 Oct 13 11:23 examples
drwxr-xr-x.  2 bjg2 unix-domainusers        6 Oct 13 11:23 incremental
-rw-r--r--.  1 bjg2 unix-domainusers    12017 Oct 13 11:25 libfoo.d
-rw-r--r--.  2 bjg2 unix-domainusers 16179042 Oct 13 11:25 libfoo.rlib
<redacted>
drwxr-xr-x.  2 bjg2 unix-domainusers        6 Oct 13 11:23 native
$ cargo test --no-run
   Compiling foo v0.1.0 (file:///<redacted>/foo)
    Finished dev [unoptimized + debuginfo] target(s) in 12.95 secs
$ ll ../../target/debug/
total 101960
drwxr-xr-x. 26 bjg2 unix-domainusers     4096 Oct 13 11:23 build
-rwxr-xr-x.  2 bjg2 unix-domainusers 63794512 Oct 13 11:27 foo-78de3a28dc680879
-rw-r--r--.  1 bjg2 unix-domainusers    12026 Oct 13 11:27 foo-78de3a28dc680879.d
drwxr-xr-x.  2 bjg2 unix-domainusers    12288 Oct 13 11:27 deps
drwxr-xr-x.  2 bjg2 unix-domainusers        6 Oct 13 11:23 examples
drwxr-xr-x.  2 bjg2 unix-domainusers        6 Oct 13 11:23 incremental
-rw-r--r--.  1 bjg2 unix-domainusers    12017 Oct 13 11:27 libfoo.d
-rw-r--r--.  2 bjg2 unix-domainusers 16179042 Oct 13 11:25 libfoo.rlib
<redacted>
drwxr-xr-x.  2 bjg2 unix-domainusers        6 Oct 13 11:23 native

[carols10cents]

Ok, reopening! Just to check, you did mean Rust 1.12, correct? Not Rust 1.21 by chance?

[BenjaminGill-Metaswitch]

Sorry - yes. Rust 1.21. I've edited in the correct version.

[carols10cents]

Whew! I was worried for a second there :)

[ehuss]

I believe @BenjaminGill-Metaswitch's issue is fixed by #4592. --all-targets will now really do "all targets".

[Tudyx]

cargo test --all-targets won´t go until generate the binary into target/debug but will detect error inside the main.rs, is it the intended behavior?

[weihanglo]

@Tudyx, I believe it is because cargo test runs integration tests, which requires binaries to exist. See this doc for more. If the relevant doc is insufficent or unclear, please open a new issue or submit a pull request to fix it. Thank you!