Run cargo clean before building for target

[gnunicorn]

Using cross with build scripts breaks sometimes, see cross-rs/cross#39 . By cleaning first, we ensure we don't fail because of reusing build-scripts.

Fixes #60 .

[johannhof]

That eliminates the effect of caching, so you might as well just remove cache:cargo from your .travis.yml. That way you avoid Travis time for cleaning and caching.

IMO this is a too broad approach that will yield a significant disadvantage (a lot slower build time) to most projects.

To preserve caching for your project maybe consider only not caching the affected files by using directory-based caching (like https://github.com/cobalt-org/cobalt.rs/blob/master/.travis.yml#L49).

[gnunicorn]

@johannhof agreed. However, I don't understand the build-steps part good enough to actually figure out which parts can and can't be cached. I'd leave the PR open for now, so ppl can find and fix it easily themselves until we have a better solution.

[japaric]

cargo clean shouldn't be necessary. The link problem you mention can happen, afaik, in two scenarios

• Calling cross build with two or more different targets within the same Cargo project.

• Using cargo build and cross build within the same Cargo project.

Trust doesn't run into any of these situtations, afaik. So you may want to check the modifications you have done to the initial template.

[gnunicorn]

Ah. then this isn't a usual problem then. Yes, we are running cargo test outside of cross (I wasn't aware that it uses docker internally before digging into it) as the lib in question has integration tests with the system which require packages, they don't run in the docker containers. Not sure how usual that is of a use case...

[japaric]

@gnunicorn You can use custom Docker images with cross. You could install the extra stuff you need in those images. Not sure if that would be enough for your case; it depends on the type of integration tests you are running.