3 ms·
Cargo is built in a way that makes it very difficult to avoid and yet it fails to understand basic cross compilation cases correctly which make it (ironically)
by saurik 4y ago
Cargo is built in a way that makes it very difficult to avoid and yet it fails to understand basic cross compilation cases correctly which make it (ironically) infuriating for people working on embedded use cases as well as for people attempting to do production binary deployments. Meanwhile, the tool just fundamentally refuses to support reproducible builds in such scenarios even though Rust is fully capable of it (I finally had to write a wrapper for the Rust compiler to munge a the arguments passed by Cargo to remove their semantic mistakes).
I feel like the problem is that it isn't just a package manager... it insists on simultaneously being not only "a" but "the" build tooling, which is trading way too much flexibility for a very small amount of convenience. And like, OK: maybe this is useful for people who are just getting started, but I would firmly argue that this kind of tooling should consider the needs of the expert and not make severe tradeoffs for the needs of the beginner unless it is trivially and obviously optional and there can be growth through changes in tooling (where maybe people "graduate" from Cargo to a more extensible tool... but since it is also the package manager, that's brutal).
The issues for the tool are then riddled with bugs that have been open for years (I think some of the ones that I've been blocking on might already be at 5 years, which is shocking to me as I don't even think of it being very old) that even often have multiple reasonable pull requests filed but where no progress ever gets made on fixing the problems because, even though it is often trivially shown that there is no way to use the tools correctly currently in the general case, they insist that the behavior of a working tool might break some theoretical user relying on the current inconsistent set of behaviors.
The result of all of this is that there are a ton of workarounds for Cargo that projects have started to have to embed almost as boilerplate into their projects, including a popular one that is going around right now (required for Linux->Linux cross) involving setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly. It is honestly infuriating and ridiculous and there are good reason why you keep seeing stuff like Google avoiding it entirely as part of their Bazel integration.
- trilobyte 4y agoOn the reproducibility problem, there are several tools for working on the reproducibility at the byte-level. That's a strength of cargo that people can work on those problems and make it part of the ecosystem.
- steveklabnik 4y agoI both agree and disagree with a lot of the things that you're saying, but rather than get into all of that, one tiny thing: > setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly. This has nothing to do with Cargo, if you're talking about RUSTC_BOOTSTRAP. This is because the kernel would like to use a stable compiler, but unstable features. This isn't a supported build configuration; the environment variable is an escape hatch for the bootstrap process, and isn't intended for nothing more. It would be, imho, unreasonable to expect Cargo to support something that is explicitly not intended to be supported.