关于构建系统
一切事物的基础是构建系统。从ROS 1迭代 catkin ，我们创建了一组 | 包 | 以 ament 命名。将名称更换为 ament 的一些原因是我们希望不和 catkin 冲突 (以防我们需要在一些点上混合使用他们) 并且防止混淆现有 catkin 文档。 ament 的主要职责是使开发和维护ROS 2核心 | 包 | 变得更容易。然而，这一责任延伸到任何愿意使用我们的构建系统约定和工具的用户。此外，它应该使 | 包 | 符合惯例，这样开发人员应当能够选择任何基于 ament 的 | 包 | 并对它如何工作、如何自检以及如何构建或使用它做出一些符合惯例的假设。 [Alyssa@9546]
ament 由以下几个重要的仓库组成，这些仓库均位于 ament GitHub 组织中： [Alyssa@9547]
ament_package 包 [Alyssa@9548]
该仓库位于 GitHub 网站的 ament/ament_package ，包含一个单独的: 术语: ament Python package ，为 |ament包| 提供各种实用程序，例如环境勾子的模板。 [Alyssa@9549]
无论其基础构建系统如何，所有 |ament包| 必须在包的根目录下包含单个: 术语: package.xml 文件。术语: package.xml "清单" 文件包含处理和操作 |包| 所需的信息。此 |包| 信息包括 |包| 的名称 (全局唯一) 和包的依赖项。术语: package.xml 文件也用作标记文件，指示 |包| 在文件系统上的位置。 [Alyssa@9550]
解析 :术语: package.xml 文件由 catkin_pkg 提供的 (和在ROS 1中一样)，而通过在文件系统中搜索 :术语: package.xml 文件来定位 |包| 的功能由构建工具提供，如 colcon 。 [Alyssa@9551]
- package.xml
包清单文件，它标记一个 :术语:
包的根，并包含有关: 术语:包的元信息，包括其名称、版本、描述、维护者、许可证、依赖项等。清单的内容采用机器可读的XML格式，内容在 REPs 127 和 140 中进行了描述，并有可能在将来进行进一步修改 REPs。 [Alyssa@9553]
所以任何时候一些 |包| 被称为: 术语: ament包 时，它意味着它是一个单独的软件单元 (源文件、构建文件、测试、文档、和其他资源)，使用一个: 术语: package.xml 清单文件进行描述。 [Alyssa@9554]
- ament包 [Alyssa@9555]
任何包含一个: 术语:
package.xml文件，并遵循ament的打包指南的 |包|，无论基础构建系统如何，就叫做ament包。 [Alyssa@9556]
由于术语: ament package 与构建系统无关，因此可以有不同种类的 |ament包|，例如: 术语: ament CMake 包 ，: 术语: ament Python 包 等。 [Alyssa@9557]
以下是您可能在此软件堆栈中遇到的常见包类型的列表: [待校准@9558]
- CMake包 [待校准@9559]
任何包含一个普通的CMake项目和一个: 术语:
package.xml清单文件的 |包| 即为CMake包。 [Alyssa@9560]- ament CMake包 [Alyssa@9561]
A: 术语:
CMake 包也遵循ament打包指南。 [Alyssa@9562]- Python包
任何包含一个基于 setuptools 的Python项目和一个: 术语:
package.xml清单文件的 |包| 即为Python包。 [Alyssa@9564]- ament Python包 [Alyssa@9565]
A: 术语:
Python 包也遵循ament打包指南。 [Alyssa@9566]
ament_cmake 仓库 [Alyssa@9567]
位于 GitHub 网站的 ament/ament_cmake 中，仓库包含许多 "ament CMake" 和纯CMake包，它们提供了创建 "ament CMake" 包所需的CMake基础设施。在这种情况下， "ament CMake" 包意味着: 使用CMake构建的 ament 包。因此，该仓库中的 |包| 提供了必要的CMake函数/宏和CMake模块，以方便创建更多 "ament CMake" (或 ament_cmake ) 包。这种类型的包可以在: 术语: package.xml 文件的 <export> 标签中用 <build_type>ament_cmake</build_type> 标签标识。 [Alyssa@9568]
这个仓库中的 |包| 是非常模块化的，但是有一个单独的 "bottleneck" |包| 叫做 ament_cmake 。任何人都可以依靠 ament_cmake |包| 来获得这个仓库中 |包| 的所有综合功能。以下是仓库中的 | 包 | 的列表以及简短说明: [Alyssa@9569]
ament_cmake聚合该仓库中的所有其他 |包| ，用户只需要依赖此包即可。 [Alyssa@9571]
ament_cmake_auto提供方便的CMake函数，自动处理编写 |包| 的
CMakeLists.txt文件的许多繁琐部分 [Alyssa@9573]
ament_cmake_core为
ament提供所有内置的核心概念，例如环境钩子、重建源文件索引、符号链接安装等 [Alyssa@9575]
ament_cmake_gmock增加了用于制作基于gmock的单元测试的便利功能
ament_cmake_gtest增加了制作基于gtest的自动化测试的便利功能 [Alyssa@9579]
ament_cmake_nose为基于python的nosetests自动测试添加了便利功能 [Alyssa@9581]
ament_cmake_python为包含Python代码的 |包| 提供CMake函数 [Alyssa@9583]
ament_cmake_test使用 CTest 在单个目标下聚合不同类型的测试，例如gtest和nosetests [Alyssa@9586]
ament_cmake_core |包| 包含许多CMake基础设施，可以使用传统接口在 |包| 之间干净地传递信息。这使得 |包| 与其他 |包| 有更多解耦的构建接口，促进了它们的重用，并鼓励不同 |包| 的构建系统中的相同约定。例如，它提供了一种标准方式来传递 |包| 之间的包含目录、库、定义和依赖关系，以便此信息的用户可以以传统方式访问此信息。 [Alyssa@9587]
ament_cmake_core |包| 还提供了 ament 构建系统的功能，如符号链接安装，它允许您从源文件空间或构建空间象征性的链接文件到安装空间，而不是复制它们。这允许您只安装一次，然后像Python代码和配置文件一样编辑非生成资源，而不必重新运行安装步骤使它们生效。这个特性从本质上取代了 catkin 的 "devel space" ，因为它具有大多数优点，几乎没有并发症或缺点。 [Alyssa@9588]
[需手动修复的语法] ament_cmake_core 提供的另一个功能是 | 包 | re源文件索引，这是 | 包 | 指示它们包含某种类型的re源文件的一种方法。此功能的设计使回答简单问题变得更加有效，例如 | 包 | 在此前缀中 (例如g. /usr/local )，因为它只要求您在该前缀下的单个可能位置列出文件。您可以在re源文件的 design docs 中阅读更多关于这个特性的信息。 [待校准@9589]
像 catkin 一样， ament_cmake_core 也提供环境设置文件和 |包| 特定的环境钩子。环境设置文件，通常被命名为 setup.bash ，是 |包| 开发人员定义使用其 |包| 所需的环境更改的地方。开发人员可以使用 "环境钩子" 来执行此操作，该命令本质上是一个任意一小块shell代码，该代码可以设置或修改环境变量，定义shell函数，设置自动完成规则等等…… 此功能如何，例如，ROS 1 可以在 catkin 对ROS分布一无所知的情况下设置 ROS_DISTRO 环境变量。 [Alyssa@9590]
ament_lint 仓库 [Alyssa@9591]
该仓库位于 GitHub 仓库的 ament/ament_lint ，提供多个 |包| 以方便、一致的方式提供linting和测试服务。目前有 |包| 支持使用 uncrustify 的 C++风格linting，使用 cppcheck 的静态C++ 代码检查，在源文件中检查版权，使用 pep8 的Python风格linting等。助手包的列表将来可能还会增加。 [Alyssa@9592]
构建工具
构建工具通过一次调用来执行一起构建工作空间中所有包的任务。对于ROS 2到Ardent的发行版本，提供此功能的构建工具被称作 ament_tools 。从ROS 2 Bouncy开始，如 通用构建工具文章 中所描述的， ament_tools 已经被 colcon 取代。 [Alyssa@9594]