So I just had a random thought:
What if Cargo and the crates.io infrastructure was extended to allow up/downloading not just the source forms of crates but also binary artifacts e.g o/so/dylib/dll/rlib files?
There is of course an immediate questions that arises: what about the combination of OS/ABI/build flags, each of which means a different output file?
What I think about that is that while technically there is a combinatorial explosion, in practice that explosion is pretty much contained by the fact that there are only so many OSes, ABIs and build flags per crate, and most of the combinations if not all can be automatically derived from the project’s Cargo.toml. Next to that, if this idea is recursively applied, it would mean that building each of those artifacts would not nearly cost as much time to build as it does now, and thus becomes more realistic to do across the ecosystem in practice.
So the idea would basically be to have pre-built binary versions of each of those combinations per crate, and then have Cargo select the correct ones for dependencies depending on compile target for the “current” project. Custom builds would work as they do now.
For crates with lots of transitive dependencies, this could cut build time very significantly I think.
But I also imagine this idea must have arisen in the Cargo dev group before, especially since it’s not a new idea e.g Debian has been doing this on the package level since Time Immemorial.
So keeping in mind the potential build time gains for all but the most trivial of projects, what would be the problems with this for Cargo?*
*Apart from the fact that there would need to be some kind of infrastructure to build and store all the artifacts I mean.
EDIT: what’s with the pie next to my name? ️