Cargo参数配置
筒子们好，我们又见面了。之前第5章，我们一起探讨了cargo的一些常用的基本技能。通过第5章的学习，大家基本能解决日常项目开发中遇到的大多数问题。但实际上，cargo提供给我们所使用的功能不仅限于此。我只想说一个字：cargo很好很强大，而且远比你想象的强大。 本章将深入探讨cargo的一些细节问题，这包括以下几个方面：
基于语义化版本的项目版本声明与管理
cargo的toml描述文件配置字段详细参考
基于语义化版本的项目版本声明与管理
我们在使用toml描述文件对项目进行配置时，经常会遇到项目版本声明及管理的问题，比如：
[package]
name = "libevent_sys"
version = "0.1.0"
[dependencies]
libc = "0.2"这里package段落中的version字段的值，以及dependencies段落中的libc字段的值，这些值的写法，都涉及到语义化版本控制的问题。语义化版本控制是用一组简单的规则及条件来约束版本号的配置和增长。这些规则是根据（但不局限于）已经被各种封闭、开放源码软件所广泛使用的惯例所设计。简单来说，语义化版本控制遵循下面这些规则：
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
关于语义化版本控制的具体细节问题，大家可以参考这里，我不再赘述。
cargo的toml描述文件配置字段详细参考
[package]段落
啥也不多说了，直接上例子，大家注意我在例子中的中文解释，个人觉得这样比较一目了然：
依赖的详细配置
最直接的方式在之前第五章探讨过，这里不在赘述，例如这样：
与平台相关的依赖定义格式不变，不同的是需要定义在[target]字段下。例如：
自定义编译器调用方式模板详细参数
cargo内置五种编译器调用模板，分别为dev、release、test、bench、doc，分别用于定义不同类型生成目标时的编译器参数，如果我们自己想改变这些编译模板，可以自己定义相应字段的值，例如（注意：下述例子中列出的值均为此模板字段对应的系统默认值）：
需要注意的是，当调用编译器时，只有位于调用最顶层的软件包的模板文件有效，其他的子软件包或者依赖软件包的模板定义将被顶层软件包的模板覆盖。
[features]段落
[features]段落中的字段被用于条件编译选项或者是可选依赖。例如：
如果其他软件包要依赖使用上述awesome软件包，可以在其描述文件中这样写：
使用features时需要遵循以下规则：
feature名称在本描述文件中不能与出现的软件包名称冲突
除了default feature，其他所有的features均是可选的
features不能相互循环包含
开发依赖包不能包含在内
features组只能依赖于可选软件包
features的一个重要用途就是，当开发者需要对软件包进行最终的发布时，在进行构建时可以声明暴露给终端用户的features，这可以通过下述命令实现：
关于测试
当运行cargo test命令时，cargo将会按做以下事情：
编译并运行软件包源代码中被#[cfg(test)] 所标志的单元测试
编译并运行文档测试
编译并运行集成测试
编译examples
配置构建目标
所有的诸如[[bin]], [lib], [[bench]], [[test]]以及 [[example]]等字段，均提供了类似的配置，以说明构建目标应该怎样被构建。例如（下述例子中[lib]段落中各字段值均为默认值）：
Last updated
Was this helpful?