At present, cargo_src_compile calls "${CARGO} build …", and cargo_src_test calls "${CARGO} test …". This has the unfortunate consequence that compilation of unit tests is deferred until the src_test phase. If it would be acceptable for all cargo.eclass-inheriting ebuilds to have IUSE="test" RESTRICT="!test? ( test )", then cargo_src_compile could call "use test && ${CARGO} test --no-run …" to build the unit tests in the src_compile phase. At present, this is a workaround: src_compile() { cargo_src_compile use test && cargo_src_test --no-run }
Yeah, this has been a gripe of Eli for some time. It doesn't help that tests sometimes require rebuilds of crates with different features and I think sometimes may even affect the image. I think the suggested workaround / change is not unreasonable (perhaps with some eclass var to suppress it to avoid a useless USE=test in some cases) but let's see what others say.
(In reply to Sam James from comment #1) > It doesn't help that tests > sometimes require rebuilds of crates with different features and I think > sometimes may even affect the image. Indeed, sometimes building the unit tests requires rebuilding dependencies because of changed features, but as far as I have been able to discern, the rebuilt dependencies get unique build IDs, so their build artifacts do not overwrite the original (non-test) artifacts. I do not believe that building the unit tests with "${CARGO} test --no-run" affects the original build products, but I am quite inexperienced with Rust, so I may be wrong.
(In reply to Matt Whitlock from comment #2) (In the same boat as you. I meant to add a caveat that I wasn't sure if I was misremembering that latter part or not.)
(In reply to Matt Whitlock from comment #2) > (In reply to Sam James from comment #1) > > It doesn't help that tests > > sometimes require rebuilds of crates with different features and I think > > sometimes may even affect the image. > > Indeed, sometimes building the unit tests requires rebuilding dependencies > because of changed features, but as far as I have been able to discern, the > rebuilt dependencies get unique build IDs, so their build artifacts do not > overwrite the original (non-test) artifacts. I do not believe that building > the unit tests with "${CARGO} test --no-run" affects the original build > products, but I am quite inexperienced with Rust, so I may be wrong. I can confirm with extreme prejudice (because I'm very prejudiced against cargo and its insanities). I encountered this issue with dev-util/ruff originally. See for more explanation: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f10d64828e9c33b2a1951c9a0e1fa84e4a736875 or github link as gitweb is currently down: https://github.com/gentoo/gentoo/commit/f10d64828e9c33b2a1951c9a0e1fa84e4a736875 If you run "cargo build && cargo test" the unique build IDs may theoretically help you inasmuch as intermediate artifacts are available for both the ordinary release binary and the test-instrumented binary. It unfortunately does not remotely mean that the "dobin" calls see the binary you intend to be installed. If you use cargo_src_install I believe it will go ahead and compile the binary a third time and that one will be a release binary again. Anecdotally, I believe it didn't tend to be any shorter than the original cargo_src_compile, though I have no idea why my anecdotal experiences weren't taking advantage of cached intermediate artifacts. I do know that the tests don't share any intermediate artifacts anyway, so using a separate target directory felt clean to me. cargo_src_install will recompile the executable during install anyway, technically. I have zero confidence that it reliably avoids recompiling. Certainly it depends how you pass additional arguments to cargo build, because "cargo install" recomputes all features and arguments and environment variables etc and then tries to bring the build artifacts up to date again using the new configuration. But hey, at least it will recompile the test executable with your release artifact flags. :)
