catkin_package()是什么意思？

DEPENDS 和 CATKIN_DEPENDS 用来告诉 catkin 需要将你程序包A的哪些依赖项传递给使用 find_package(...) 查找你的程序包的程序包B。

而在CMakeLists.txt中正好可以找到find_package()和catkin_package()，也就是说，catkin_package()是作用在find_package()中的。

1 cmake_minimum_required(VERSION 2.8.3)
2 project(beginner_tutorials)
3
4 ## Find catkin and any catkin packages
5 find_package(catkin REQUIRED COMPONENTS roscpp rospy std_msgs genmsg)
6
7 ## Declare ROS messages and services
8 add_message_files(DIRECTORY msg FILES Num.msg)
9 add_service_files(DIRECTORY srv FILES AddTwoInts.srv)
10
11 ## Generate added messages and services
12 generate_messages(DEPENDENCIES std_msgs)
13
14 ## Declare a catkin package
15 catkin_package()
例如，假设你 find_package(Boost REQUIRED)，并在你的安装的头文件中有代码行 #include <boost/functio n.hpp>。为使一个依赖于你的拥有#include<boost/function.h>的程序包能使用你的头文件，它们需要在自己的 include 路径中包含 Boost 的 include目录（其实在visual c++中#include该头文件是不是同理），还需要连接 Boost 的库（同前文注释）。由于你已经在头文件中导出（是从程序中的#include导出的吗？）（难道说在visual c++中的#include是一级操作，接下来的操作是生成类CMakeLists.txt这样的文件？）该依赖，它们应该能从你那里获得依赖。也就是它们不再需要 find_package(Boost REQUIRED)（也就是依赖一个包，而被依赖的这个包不需要重复声明它的依赖项） ，因为它们是使用你的包构建的，而不是直接使用 Boost。

你的程序包（是一级依赖还是二级依赖？从后文看，应该是一级依赖）依赖于 Boost 这一事实是一个实现细节，因此当一些包（一级包）通过 find_package(...) 查找你的包（二级包）时，它们（一级包）能间接获得对 Boost 的依赖。让这种机制起作用方法是在你的 catkin_package(...) 调用中加入 DEPENDS Boost参数（在二级包中）（加上DEPENDS Boost就能依赖于被依赖包的依赖项）。其实现细节是：

catkin 将 find_package(Boost)（作用于全局）
并向 ${your_pkg_LIBRARIES} 添加 ${Boost_LIBRARIES}（作用于一级包）
向 ${your_pkg_INCLUDE_DIRS} 添加 ${Boost_INCLUDE_DIRS}。（作用于二级包）
your_pkg_LIBRARIES应该是使用Boost的包，结合上文应该是为这个包的运行环境维护了很多变量，比说x现在说到的your_pkg_LIBRARIES。

我们应该注意，catkin 将 find_package() 你告诉它的确切的程序包名， 然后尝试使用该包的 _LIBRARIES 和 _INCLUDE_DIRS 变量（证明每一个库还在UBUNTU环境下还拥有很多变量）。但是 find_package(...) 得到的结果变量的形式并不总是这样（结合下文，应该说的是变量名称不是固定的），因为 CMake 没有强制执行此操作（这句话的意思应该是CMake没有强制约定命名规则？）。例如当 find_package python包时，find_package(PythonLibs REQUIRED) 的结果变量的形式为：PYTHON_INCLUDE_PATH(这是对your_pkg_DIRS进行赋值之后的值，PYTHON_INDLUDE_PATH对应Boost_INCLUDE_DIRS,应该注意的是，它们的命名规则是不一致的，如果一致的话，PYTHON_INCLUDE_PATH应该叫PYTHON_INCLUDE_DIRS)。

find_package(OpenGL REQUIRED) 的结果变量为 OPENGL_INCLUDE_DIR。（这个时候命名规则与添加Boost库的例子又一致了）。

除了变量前缀变得不一样（PythonLibs -> PYTHON），后缀也变得不标准（PYTHON_INCLUDE_PATH and OPENGL_INCLUDE_DIR vs *_INCLUDE_DIRS，在这句话中有三种后缀，分别是PATH和DIR以及DIRS）。在这种情况下你就需要使用INCLUDE_DIRS 选项将传递包含头文件目录的变量到catkin_package()中（这个变量的意思是include dirs），同理LIBRARIES选项也是干的类似的事情。

CATKIN_DEPENDS 选项和 DEPENDS 选项十分相似，但是对于CATKIN_DEDPENS来说,你只能在其列表中放置 catkin 程序包(即是用roscreate-pkg创建的程序包)。将 catkin 依赖设置为一个单独的选项的好处是可以让 catkin 执行一些额外的检查，然后警告你有什么不妥的做法。

最后，给个简单的示例 CMakeLists.txt：

cmake_minimum_required(VERSION 2.8.3)
project(foo)

find_package(Boost REQUIRED COMPONENTS
system
thread
)

find_package(PythonLibs REQUIRED)
find_package(OpenGL REQUIRED)

find_package(catkin REQUIRED COMPONENTS
rosconsole
roscpp
)

include_directories(
include
${catkin_INCLUDE_DIRS}
${OPENGL_INCLUDE_DIR}
${PYTHON_INCLUDE_PATH}
)

catkin_package(
INCLUDE_DIRS include ${OPENGL_INCLUDE_DIR}
LIBRARIES foo ${OPENGL_LIBRARIES}
CATKIN_DEPENDS roscpp
DEPENDS Boost
)

...

此例中你可以看到我 find_package(find_package(Boost REQUIRED COMPONENTS))并将它传递给 catkin_package() 的 DEPENDS 部分(catkin_package(DEPENDS Boost))。因为它（catkin_package()）生成的是兼容 CMake 的变量(变量格式一致???)。

在CMakeLists.txt文件中find_package(PythonLibs REQUIRED)，但是不用将它传递给 catkin_package()，因为我没有在我任何暴露给外界的头文件中包含它。我 find_package(OpenGL...) ，由于它生成的不是兼容 CMake 的变量，所以我将其显示地传递给 catkin_package() 的 INCLUDE_DIRS 和 LIBRARIES 部分，（不用变量了，直接赋值）。最后，我 find_package(catkin ... rosconsole roscpp，并在内部使用，但是我可能只在 .c* 文件中使用了 rosconsole，因此我不用传递它，所以 catkin_package() 的 CATKIN_DEPENDS 部分我只需放入 roscpp。

最后要说明但是，如果一个程序包有直接使用像 Boost 这样的依赖项，那么它们应该确保用 find_package(...) 显示地查找它，而不是通过其他包隐式地依赖于它。举个这样的例子，如果程序包 foo 将 Boost 作为依赖项导出，又有程序包 bar 依赖于 foo，但也在内部使用 Boost，那么 bar 即使在没有显示依赖 Boost 的情况下也能编译正常。 但后来 foo 可能决定重构并删除了它对 Boost 的依赖，那么现在 bar 将无法编译，因为它不再具有通过 foo 传递来的对 Boost 的隐式依赖。