用Cargo进行源代码构建(外部构建目录)不足? [英] Out of source builds (external build directory) with Cargo?

查看:174
本文介绍了用Cargo进行源代码构建(外部构建目录)不足?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

使用过CMake之后,我已经习惯了源代码外的构建,CMake鼓励这样做。如何使用Cargo进行源代码外构建?

Having used CMake, I've become used to out-of-source builds, which are encouraged with CMake. How can out-of-source builds be done with Cargo?

再次使用源代码内构建感觉就像是一步向后:

Using in-source-builds again feels like a step backwards:


  • 需要配置开发工具以忽略路径。有时会有多个插件和开发工具-尤其是使用VIM或Emacs!

  • 某些工具无法配置为轻松隐藏构建文件。虽然通常隐藏点文件,但它们仍将显示 Cargo.lock target / ,更糟糕的是,递归地公开其内容

  • 删除未跟踪的文件删除版本控制之外的所有内容,通常是清理编辑器临时文件或某些测试输出,如果您忘记向版本控制中添加新文件并且不手动检查文件,可能会适得其反

  • 依赖项会下载到您的源代码路径中,有时会在<$ c中添加 *。rs 文件$ c> target 目录是构建间接deps的一部分,因此对所有 *。rs 文件进行操作可能会意外拾取其他不在目录中的文件隐藏的目录,因此即使配置了开发工具也可能不会被忽略。

  • Development tools need to be configured to ignore paths. Sometimes multiple plugins and development tools - especially using VIM or Emacs!
  • Some tools can't be configured to easily hide build files. While dotfiles are typically hidden, they will still show Cargo.lock and target/, worse still, recursively exposing their contents.
  • Deleting un-tracked files to remove everything outside of version control, typically to cleanup editor temp files or some test output, can backfire if you forgot to add a new file to version control and don't manually check the file list properly before deleting them.
  • Dependencies are downloaded into your source code path, sometimes adding *.rs files in the target directory as part of building indirect deps, so operating on all *.rs files may accidentally pickup other files which aren't in a hidden directory, so might not be ignored even after development tools have been configured.

虽然可以解决所有这些问题, sues,我只希望有一个外部构建路径并保持源目录原始。

While it's possible to work around all these issues, I'd rather just have an external build path and keep the source directory pristine.

推荐答案

您可以指定 target / 文件夹的目录,可通过配置文件(键 build.target-dir 环境变量( CARGO_TARGET_DIR 。这是一个使用配置文件的示例:

You can specify the directory of the target/ folder either via configuration file (key build.target-dir) or environment variable (CARGO_TARGET_DIR). Here is an example using a configuration file:

假设您要拥有目录〜/ work / 您要保存Cargo项目(〜/ work / foo / ),并在其旁边保存目标目录(〜/ work / my-target / )。

Suppose you want to have a directory ~/work/ in which you want to save the Cargo project (~/work/foo/) and next to it the target directory (~/work/my-target/).

$ cd ~/work
$ cargo new --bin foo
$ mkdir .cargo
$ $EDITOR .cargo/config

然后将以下内容插入配置文件:

Then insert the following into the configuration file:

[build]
target-dir = "./my-target"

如果您随后在常规的Cargo项目目录中进行构建:

If you then build in your normal Cargo project directory:

$ cd foo
$ cargo build

您会注意到没有 target / 目录,但是所有内容都在〜 / work / my-target /

You will notice that there is no target/ dir, but everything is in ~/work/my-target/.

但是, Cargo.lock 仍保存在货运项目目录,但是有点道理。 对于可执行文件,您应该将 Cargo.lock 文件签入git!对于图书馆,您不应该。我想必须忽略一个文件比必须忽略整个文件夹要好。

However, the Cargo.lock is still saved inside the Cargo project directory, but that kinda makes sense. For executables, you should check the Cargo.lock file into your git! For libraries, you shouldn't. I guess having to ignore one file is better than having to ignore an entire folder.

最后,更改目标目录有一些警告,列出了<在PR中引入了该功能的href = https://github.com/rust-lang/cargo/pull/1657 rel = noreferrer> 。

Lastly, there are a few caveats to changing the target-dir, which are listed in the PR which introduced the feature.

这篇关于用Cargo进行源代码构建(外部构建目录)不足?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆