Figure a way to not rebuild everything

[roblabla]

This crate specifies a cargo version (0.13) in order to use its internal state instead of relying on stdout/stderr and hoping its output format stays the same.

This causes problems, however, since versions of cargo are not compatible with eachother. Meaning if, with cargo 0.12 installed, I did a cargo build followed by a cargo coverage, the coverage will trash all the work done by the build and recompile the world. This is because cargo versions are incompatible.

This wouldn't be a problem if I could specify the cargo version. But across releases, cargo versions are wildly incompatible.

It'd be nice if cargo had a stable core we could build tooling with.

[WaDelma]

One (hacky) way to fix this would be to move existing cargo files to somewhere else and then back after just before command ends.

[spacekookie]

I was personally thinking about setting up a PPA which builds kcov and then offers a binary deb package to install which would be a lot faster than compiling it from source every time. Could we do the same with the cargo-travis crate as well? Essentially building it once for the PPA and then just having a binary dependency to install.

I've never done anything with PPA's but I guess this could be useful for a whole bunch of people. Because 15-20 minutes build time for my crate kinda sucks 😞

[roblabla]

@spacekookie this is a different issue. For what you're talking about (the fact we have to build kcov and this crate), look at #11 and #17. Basically the solution is cargo install cargo-travis || echo "cargo-travis already installed" and using the cargo cache.

[roblabla]

#52 would help but not fix this.

While using the same cargo version brings us a step closer to being able to reuse artifacts, it is still not possible yet because of our use of RUSTFLAGS. Cargo will consider builds with different RUSTFLAGS as not being "compatible", and as such not reuse the artifacts.

The RUSTFLAGS munging is done to link dead code and inject debuginfo in release builds. There's a pretty easy way to inject the flag: Using cargo rustc instead of cargo build, we can do cargo rustc -- -C link-dead-code. It seems to do what we want - this is because link-dead-code only changes how rustc interacts with the linker (the final step of the compilation process).

The same trick seems to work for injecting debuginfo, surprisingly. I expected doing this wouldn't get the intended behavior, because debuginfo needs to be generated for the crate and all of its dependencies. But I suppose cargo always builds with debuginfo, and only strips them at the end, since doing cargo rustc --release && cargo rustc --release -- -C debug-info=2 generates a binary that has full debug info, including for the dependencies (checked by running dwarfdump and looking for .cargo/registry).

One fairly big downside is that cargo rustc only supports passing arguments to a specific "target" (where target means a specific binary/library/whatever here). So to support multi-target scenarios (workspaces, a crate with multiple binaries/a binary and a library), we'll need to add some logic to get the list of targets, and build them individually.