Weihang Lo
u/weihanglo
Feed options
Hot
New
Top
View
Card
Compact
Guess I'll have to keep my eye out for
.cargo/config.tomlfiles. At least the documentation reads like cargo wouldn't parse that file in 3rd party crates - but I didn't test, and some crates do publish with config.toml files.
Cargo only respects .cargo/config.toml from cwd up to root. .cargo/config.toml from dependencies are ignored, so config.toml in crates.io tarballs do nothing to your local package.
imo decoupling from rustc would be a big headache as it would require supporting a large variety of rustc versions. Not just in production but for testing so we make sure they work!
You are aboslutely right, and that's why it is just a dream. I can imagine how painful maintaining Rust Analyzer would be if Cargo and rustc had different versions. I should have called out explicitly that is me not believing myself can find good approaches to fix one thing without breaking the other.
If we encourage the proliferation of these tools, I feel like we would lose one of the major value-adds of cargo: its standard.
Both agree and disagree. We love how easy we just invoke cargo build and call it a day. We hate being locked-in Cargo and hard to integrate into other build systems.
The proposed solution in this post is never "creating a new tool an split the community". I am not good enough to make it happen either. The gist of it is finding a space to experiment, and calling out a set of things a tool shall respect if they want the community healthy. It is wonderful if every possibility is built-in in Cargo :)
A lot more is needed than the
Summary, like target discovery.
For binaries crates, definitely yes. If one package just depends on .rlib, then fancy target discovery isn't really needed (perhaps only src/lib.rs discovery and 2015 edition case).
For this specific one there is less maintenance so can just keep it here.
We can always say sorry and remove nightly features. It is just nicer having alternatives before doing so. Another example is that --out-dir has been renamed to --artifact-dir but the original flag is kept for compatibility.
This is a summary of my thoughts as a maintainer of Cargo. Some parts are currently under active development (like the resolver and mtime cache), while others still need more attention. If you're willing to help, I recommend subscribing to the "This Development-cycle in Cargo" series, which also highlights areas needing helps.
