Travis (and may be others?): saving power with help of sccache?

[davemilter]

As I know there are 14_005 crates available via https://crates.io also there are a lot of rust code not published yet. Many of theses packets use at least https://travis-ci.org/ and https://ci.appveyor.com/ .

And of course almost all of these rust code uses cargo and depend on some other packets. So many machines in the clouds again and again build the same packages with the identical preferences.

I wonder anybody discuss possibility to build for each version of package submitted to crates.io in two variants for ubuntu/windows which are used in Travis/Appveyor, convert these binaries to sccache internal cache and share via some protocol. I suppose Travis/Appveyor can take care about sharing part, because of it should speedup builds and save money for them.

What do you think?

[killercup]

build for each version of package submitted to crates.io in two variants for ubuntu/windows

The builds depend on the compiler version and feature flags and maybe even environment (available system libraries). This is not as trivial as building "two" versions.

A "global" cache of build artifacts, indexed by hash, might be interesting (and quite trendy – feel free to add "block chain" and "distributed" to the description). I am however not sure if it's truly faster than just using cache: cargo in your Travis config (which caches ~/.cargo and ./target on some storage device at Travis').

[davemilter]

@killercup

The builds depend on the compiler version and feature flags and maybe even environment (available system libraries). This is not as trivial as building “two” versions.

Yes, but

1. sccahe handle this situation, and more other things like you use or not use C/C++ code in your code, custom linker flags and so on.
2. Why handle many options, I suppose rustc stable/default gcc for default Ubuntu/and last stable MSVC will be enough to cover huge build time.

@killercup

A “global” cache of build artifacts, indexed by hash, might be interesting (and quite trendy – feel free to add “block chain” and “distributed” to the description). I am however not sure if it’s truly faster than just using cache: cargo in your Travis config (which caches ~/.cargo and ./target on some storage device at Travis’).

As I know rustc uses sccache why not take numbers from there?

Plus ~/.cargo and ~/target cache is unique for every package, while global sccache will be just one.