I have been for some time frustrated with a project which practically speaking must use .cargo/config.toml, a Rust "feature of last resort" that the Rust devs seem to almost be leaving intentionally poorly supported to disusade you from using it. Just now I found a way to solve a serious and fundamental problem .cargo/config.toml normally causes, and I'm split between feeling very satisfied and really annoyed because oh my god this solution is so ugly
Now, this solution to the problem actually introduces another problem. But that second problem turns out to be fixable by using an "unstable" feature in Rust nightly. Unfortunately, the "unstable" feature in Rust nightly introduces a third problem. I will not be elaborating on this post.
UPDATE: So someone on Mastodon reads my posts here, looks at what I did, and says "why don't you just use [X]?". So I look in the docs, and realize [X] is indeed a far superior solution which is clean and does not introduce additional problems. So I try doing [X]. Long story short, it's now nearly half an hour later and after a series of tests I believe I've found a bug in the Rust compiler and I'm setting up to file a bug on Cargo
UPDATE 2: After spending an hour writing a complex bug cataloguing the apparent bug "When I move .config/cargo.toml to special-cargo.toml and specify it using --config, it always looks one level up outside the git project for the platform json, in fact, all file paths behave relative to the parent directory of the cargo.toml, always, even when they're specified with --config".
Then I find this in the docs.
What!!!
What!!!!!
Why would you do it this way!!! This is so weird and unfriendly!!!
@val yeah it means if i'm in my git project and i say --config filename.toml and that toml specifies a json it's going to be looking entirely outside my git repo just in outer space somewhere
This is the kind of thing I'd expect out of like, perl, or javascript. It screams "this is a bug from version 1.58 we can't remove because existing code relies on it continuing to work however it works". Which I guess probably means I'm not going to have any luck filing a feature request suggesting they change it :(
Thinking about this further, I guess the reason it works this way is so you can use --config to specify another project's .config/cargo.toml without changing the toml contents. I still hate it
@rain It would be a very long toml string. I'd have to do like $( cat filename ) in the makefile, or something, and I'm trying not to have a complex makefile.
@leo our config cargo.toml has six complex options in it, three of which are arrays. it also contains comments. this would mean a very complex invocation line if we moved to the --config options, which would mean a very complex makefile, and i'm already unhappy we're using a makefile (what if someday I want to build on Windows?).
In addition, the other dev made an attempt to switch to --config this morning, and came back with "it isn't working for some reason". I don't want to touch the crab
@mcc it looks relative to the cargo cwd, I wonder if that's getting changed for some reason before it gets read? you could work around this by doing $PWD/riscv32imafdc-cargo-config.toml ig, probably worth reporting as a bug though....?
Add comment