我有一系列多年来积累的项目,当我重构核心库的API时,检查和更新依赖于该库的所有应用程序变得很麻烦。 我不仅必须编写一个 shell 脚本来遍历所有这些内容,而且还需要在所有目录中重新编译相同的内容,从而占用大量磁盘空间和计算时间。
我以为我可以使用工作空间,但立即感到失望:
error: workspace member `/home/user/art/2019/equation-minis/equation-stitcher/Cargo.toml` is not hierarchically below the workspace root `/home/user/src/embroidery/Cargo.toml`
我尝试用像
ln -s ../../art .
这样的符号链接来伪造它,但失败了,因为艺术项目使用了
[dependencies]
"filler" = { path = "../../../src/embroidery/filler" }
以及货物投诉:
error: failed to load manifest for workspace member `/home/user/src/embroidery/art/2022/united-methodist`
Caused by:
failed to load manifest for dependency `filler`
Caused by:
failed to read `/home/user/src/embroidery/src/embroidery/filler/Cargo.toml`
是否有更灵活的方法将一堆 Rust 箱子视为工作空间(一致的 Cargo.lock,共享构建的工件)?
当位于工作区的子目录中时,Cargo 将自动在父目录中搜索具有
定义的Cargo.toml
文件,以确定要使用的工作区。[workspace]
清单键可在成员箱中使用以指向工作区的根以覆盖此自动搜索。如果成员不在工作区根目录的子目录内,则手动设置可能很有用。package.workspace