catkin 与 rosbuild解析及两者区别和联系

catkin 与 rosbuild解析及两者区别和联系 [官方文档翻译]
转载自wiki.ros.org/cn/catkin_or_rosbuild
本页面试图总结阐明catkin与rosbuild的不同。本页面的信息源自catkin文档，catkin API reviews，以及catkin源代码。

1. 开发catkin的动机
   使用rosbuild将ROS程序安装到其他系统或架构上是很麻烦的，这是rosbuild存在的主要问题，也是后来为何要开发catkin的原因。
   而为了解决上面这个问题，提高可移植性的关键是为ROS包提供安装目标，并服从FHS的安装布局。如果仅改变rosbuild并不是说不可能实现，但这实现似乎很难。
   所以，catkin主要的设计过程是为CMake宏、变量和python写帮助函数
   catkin的设计者们也就此试图改进catkin的使用体验，以减少在程序构建时多依赖的项目对cmake和rosbuild的使用。 而解决这些问题的动机在于，rosbuild缓慢的构建速度是被人们抱怨最多的地方。

以下是catkin主要的设计实现目标：

将白名单的文件集作为安装目标安装
兼容FHS文件布局
自动生成符合cmake的配置文件
外源构建（也用于交叉编译）
仅使用一个命令，就可以以正确的顺序构建多个项目
编译时允许使用标准cmake命令，而不是包装器的命令
在开发周期无需安装
加速编译周期，使用并行编译，对c ++文件跨相互依赖的项目编译
拆分配置和构建阶段，以提高构建速度
通过避免对资源进行多次类似rospack的查找，来提高构建速度（使用单个cmake查找）

1. 区别
   2.1功能包与功能包集的概念
   rosbuild定义了两个关键概念，即堆栈和包。包Packages是一个包含manifest.xml和源文件的文件夹。堆栈Stack是一个包含stack.xml文件的文件夹。如果包Package是堆栈stack的子文件夹（包括源代码中的安装布局），那么该包是堆栈的一部分。堆栈只能依赖于其他堆栈，包也只能依赖于其他包。

在使用catkin的时候，功能包是构建和发布的原子单位。功能包集非原子释放单元，但可用于代替堆栈。使用catkin时，源中的功能包是具有名为package.xml的清单文件和源文件的文件夹。但是，安装后，由于FHS要求，功能包文件夹中不再严格包含功能包工件。

考虑到对更加轻便的ROS安装的需求，设计者们将包作为发布的原子单元，因为不期望的包package不用与堆栈stack一起安装。以遵守FHS布局，允许在各种操作系统和架构上更轻松地安装ROS。

2.2构建过程
rosbuild中的构建过程由ROS_PACKAGE_PATH环境变量，rosmake命令和rospack库三者驱动。
rosmake命令通过爬取ROS_PACKAGE_PATH中列出的目录来找到包，然后遵守依赖关系的顺序在找到的所有包文件夹上调用make命令进行编译。 make命令通常依赖于cmake，并且都配置和构建项目源。 使用rospack库查找依赖关系，rospack库还使用ROS_PACKAGE_PATH来查找属于这些包的文件。 对于每个功能包，cmake和make被分开调用，这也重复了为几个包找到依赖的工作量。

而在catkin命令中，构建的过程由工作空间文件夹，标准cmake命令和用于查找依赖关系的cmake约定驱动。
工作空间文件夹中包含一个cmake文件，它将仅爬取catkin软件包的工作区文件夹，并配置这些文件夹的结构。在配置期间，cmake配置文件会自动生成。 依赖关系中的资源使用自动生成的cmake配置文件，而不是通过rospack来查找。这也允许第三方软件构建在已安装的ROS包上，而不需要使用任何ROS构建工具链。
对于纯cmake语句来说，CMAKE_PREFIX_PATH环境变量包含了将被搜索的位置，替换了特定于ROS的ROS_PACKAGE_PATH变量。
构建过程（调用make）只编译构建目标，潜在地允许了跨相互依赖项目（必须使用rosbuild顺序构建）并行编译文件。

因此，与rosbuild相比，catkin越来越多人使用的主要原因是：

配置一次，构建多次;仅在需要时重新配置
一次配置过程，使用cmake（只需要进行一次查找相同的依赖关系的操作）
跨越依赖项目编译（即使跨越相互依赖的项目也并行编译）
为防止可能出现的命名空间冲突，该设计有一些注意事项，主要是cmake目标具有相同的名称，其他全局（缓存）变量和多个不兼容的find_package调用。对此，解决方式是命名标准的对象和变量，孤立进行catkin构建（使用catkin_make_isolated）并拆分catkin工作区。

2.3打包
有工具链创建软件包文件可安装Ubuntu的rosbuild和catkin包。 rosbuild包与它们的源文件和编译文件一起被安装在单个文件夹中。一个堆栈中的所有包被打包到单个分发单元中，常常安装用户不想要的包。

catkin包安装时通常没有不需要运行代码的源文件。也只有用户想要安装的软件包（而不是像rosbuild一样堆栈）。

按照FHS标准的要求，catkin包的安装文件分布在多个文件夹中。 ROS仍然区分全局和本地可执行文件夹。这意味着可执行文件通常不在PATH中的全局bin文件夹中，而在lib或共享的子文件夹中（取决于它们是二进制文件还是脚本），应该使用rosrun来调用。

遵循FHS的好处是，可以轻松地为各种操作系统（Unix，BSD，其他linux发行版）和软件包管理器打包这些软件包，并且该软件可以构建在软件包之上，而不需要依赖于特殊的工具链。所以已被安装的catkin包可以很容易地重复使用，而不需要catkin重新构建。

2.4工作空间WorkSpace布局
rosbuild允许用户将包开发到ROS_PACKAGE_PATH上的任何位置。 典型的用法将鼓励单个源工作空间文件夹。 rosmake可以通过包的名称（或使用当前文件夹的回退）在任何地方被调用，并且递归地构建给定包的依赖关系图。 ROS_PACKAGE_PATH必须由用户来管理，并鼓励使用户用rosinstall / rosws命令来生成合适的*.sh安装文件，以及在许多项目中提供VCS操作。 每个项目文件夹也用作构建空间，因此每个软件包只有一个构建空间。

使用catkin时，每个构建或配置过程被严格限制在单个工作区文件夹，该文件夹中必须包含由catkin提供的cmake文件用以指导配置过程。 构建和配置过程必须从特定文件夹启动（或作为选项传递），但不可能轻易地构建单个软件包及其依赖关系中的所有目标。 由于catkin从源文件夹分离出了构建空间，因此可能会有多个构建空间。 Catkin还定义了一个开发空间和一个安装空间。 这两者都指的是生成了用于使用这些空间的.sh安装文件的源文件夹。 这意味着由rosinstall和rosws命令所生成的安装程序.sh不能再使用了。 wstool命令替换了rosinstall和rosws以仅执行VCS操作。

这些变化有利于需要多个构建空间的开发人员，例如用于交叉编译等目的。与rosbuild或纯cmake命令相比，这些更改还使得编译周期的速度有一定的提高。

默认catkin工作流依赖于以单个文件夹作为中心源文件夹，该中心源文件夹具有一个由catkin提供的CMakeLists.txt文件。这会调用一个函数，来爬取这个文件夹以供catkin包构建。这不同于rosbuild，而在rosbuild中，是使用ROS_PACKAGE_PATH确定要为要构建的包进行爬取位置列表的。因此，通过ROS_PACAGE_PATH将位置列入rosbuild的白名单。相反，在catkin中，位置被列入黑名单（所有在src文件夹中找到的包均会被使用，除非他们有一个标记文件）。

叠加方式也是不同的，因为rosbuild依靠rospack来从多个候选项中标识出具有相同名称的单个包以用于构建。这是通过使用ROS_PACKAGE_PATH作为第一优先级完成的，最早的查找作为第二优先级在ROS_PACKAGE_PATH中搜索单个位置。 catkin不允许在同一位置（src文件夹）有多个包，但允许通过链接的工作空间进行覆盖。然而，这种覆盖是不合适的，因为覆盖语义对每个工作空间来说是局部的。

2.5工程文件
使用rosbuild时，每个包需要有一个manifest.xml文件和一个Makefile文件，并且通常还有一个由Makefile使用的CMakeLists.txt文件。开发人员在CMakelists.txt文件中声明了某些构建和生成步骤，并在清单文件中声明依赖关系。为了在别的项目中起到依赖项的作用，项目还必须在manifest.xml文件中声明导出属性，这很容易出错并导致交叉编译失败。这个问题是应当尽力避免的。

catkin仍然使用包的清单文件，但其被称为package.xml。使用catkin，不再使用Makefile，作为替换，CMakeLists.txt文件是强制的。要作为依赖项，catkin自动生成配置文件，而不是使用人工制作的导出标志。开发人员需要在CMakeLists.txt中提供安装目标，这意味着他们必须指定要安装哪些文件，哪些文件不安装。这允许大大减少ROS包的下载/更新的大小。

CMakeLists.txt文件中使用的ROS特定宏命令在名称和结构上都在rosbuild和catkin中发生了变化，迁移必须手动完成，只有有限的工具支持。

package.xml和mainfest.xml文件具有不同的语法。

这些变化主要是实现设计目标所必需的。开发人员受益于配置文件的自动生成，用户从ROS包的增加的可移植性中受益。