Enable build on multiple hosts without causing a full recompile.

[hugoduncan]

When working on cross-platform code, it is useful to have a source directory mounted in several vms, with different operating systems, so changes can be rapidly tested on all targets.

When running cargo build on a different host (VM), cargo does a full recompile of the whole project, which slows down running of tests, etc.

The problem seems to be due to cargo build using paths for build artifacts that aren't scoped by the target triple.

When manually specifying a --target, the paths seem to be scoped by the target triple. Could this logic be used for the implied default triple when running without --target?

[alexcrichton]

This could in theory be done but it makes the "easy case" a little harder in that right after you run cargo build for the first time ever you've gotta go digging around in some target specific directories which you may not care too much about.

I'm a little worried about the first impression use case, but I can see where this definitely would be super annoying. Perhaps another possibility would be to always scope dependencies under target-specific directories but the crate being built sticks around in target/. Just a thought though.

[hugoduncan]

I can certainly see the utility of having the latest build artifacts under target/. Would symlinking the final artifact to target/ be sufficient?

[alexcrichton]

Perhaps! In general we've tried to shy away from symlinks as much as possible (due to complications on older Windows), but there's a whole slew of issues with that so it may not be so bad.

[carllerche]

At the very least, it would be nice for this to be a local option.

[Diggsey]

Symlinks may not work too well, even on newer windows: depending on how you share the folders, a symlinked folder on the host can appear as two ordinary, separate folders from within a VM, and vice versa.

An alternative would just be to copy the final output to target/ as a final build-step if the target is left unspecified.

[eminence]

Perhaps another possibility would be to always scope dependencies under target-specific directories but the crate being built sticks around in target/

I like this idea. For some projects, building the dependencies is the longest part of the build, so this compromise will definitely help some users.

[stale]

As there hasn't been any activity here in a while would someone (the author, a team member, or any interested party) be able to summarise the current state, perhaps making explicit:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[stale]

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!