Cargo: `cargo test` 不会覆盖最近工具链上目标/调试中的构建工件

创建于 2018-10-11 · 3评论 · 资料来源: rust-lang/cargo

请查看最小化的项目进行重现： https :
有一个工作区，其中包含一个动态库和一个依赖它的项目。图书馆有一个特点。问题是相同的构建和测试场景不适用于最近的工具链：

工作场景：
1) cargo +1.26.2 build --features feature
2） cargo +1.26.2 test --all -- --nocapture

不起作用：
1） cargo +1.28.0 build --features feature
2） cargo +1.28.0 test --all -- --nocapture

我目前的观察（在 OSX 上测试）：工作场景 - 在步骤 (1) 中，库libcargo_check.dylib在target/debug/deps目录中构建，然后复制到target/debug 。在第 (2) 步，它被重建（因为缺少功能），也复制（覆盖旧的）到target/debug ，然后执行测试应用程序，链接到target/debug中的共享库target/debug/deps但没有复制到target/debug和测试应用程序针对target/debug旧版本的动态库执行。如果我手动删除target/debug过时的libcargo_check.dylib那么cargo +1.28.0 test --all -- --nocapture按预期工作，因为测试应用程序是针对target/debug/deps中的动态库执行的。

最初的 Rust 项目是一个涉及 Java 的复杂项目的一部分，所以整个项目都是用 Maven 构建的，Maven 依次执行用于构建和测试的货物。我的期望是cargo test行为方式与之前版本的工具链中的行为方式相同。

我针对几个版本的工具链对其进行了测试，可以说它适用于 1.26.2 和 1.27.2，但不适用于 1.28.0 和 1.29.1。

提前致谢！

资料来源

skletsun

👍2

最有用的评论

感谢您调查此@ehuss！选项 (2) 对我来说听起来是解决这个问题的好方法，我绝对认为我们不应该因为在那里切换优先级而产生太大的影响，如果有必要，我们可以随时独立追求 (3)

alexcrichton 于 2018-10-11

👍2

所有3条评论

cc @ehuss ，我想我们最近在不和谐的情况下讨论过这个问题，对吧？因为这是目前预期的行为，但我们确实可以修复！（可能至少应该用于 dylib 输出）

alexcrichton 于 2018-10-11

我认为是在 #6131 中我们讨论了令人振奋的改变。

这里有很多事情：

build/test/run 命令不会清理目标目录。以前运行的工件通常无关紧要，但对于共享库，它们有时会影响。
dylib 搜索路径包括 root 目标 dir 和 deps 目标 dir，并且 root 优先（在此处交换它们可以解决此问题）

当我们改变令人振奋的时候，担心可能会有问题，但当时我们想不出任何具体的事情。看起来我们找到了一个！ 😄

我看到了三种可能的解决方案：

在每个命令运行之前清理基本目标目录。现在这里是垃圾场。但是，我不喜欢这个想法的声音。
翻转上面提到的dylib路径的顺序。
将依赖项的所有可共享库（dylib/cdylib）复制到目标中。

我没有偏好。 2 非常简单，但我不知道其中的含义。 3有点难，但可行。

ehuss 于 2018-10-11

👍1

alexcrichton 于 2018-10-11

👍2

此页面是否有帮助？

0 / 5 - 0 等级

Cargo: `cargo test` 不会覆盖最近工具链上目标/调试中的构建工件

最有用的评论

所有3条评论

相关问题