这对我来说似乎很合理,尽管我可能会说它应该在 Cargo.toml 中,因为它可能是每个项目的事情 _if_ 这是一个开始的事情。
将其设置为项目设置的一个缺点 (?) 是该设置将始终被依赖项忽略。 示例:如果我的项目 P 依赖于 crate D 并且 D 已将 T 设置为其默认目标,则该设置将_始终_被忽略,因为 D 将始终为我为 P 选择的目标编译。
使用 .cargo/config 的一个好处是,如果我在本地开发几个 crate,那么我可以有这样的设置:
$ tree .
my-RTOS-project
├── .cargo
│ └── config
├── allocator
│ └── (...)
├── hal
│ └── (...)
├── RusTOS
│ └── (...)
└── scheduler
└── (...)
我可以从一个 crate 目录跳转到另一个并运行cargo test
。 在某些时候,我可以在 .cargo/config 中编辑一行,然后开始针对不同的目标测试我的 crate。
啊哈确实是! 这在某种程度上属于https://github.com/rust-lang/cargo/issues/2122的范围,其中_不应该_是一个缺点,但仍有一些设计工作要做。
最有用的评论
这对我来说似乎很合理,尽管我可能会说它应该在 Cargo.toml 中,因为它可能是每个项目的事情 _if_ 这是一个开始的事情。