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 。为使一个依赖于你的拥有#include的程序包能使用你的头文件，它们需要在自己的 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

　　)无锡好的×××医院 http://www.zzch220.com/

　　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 的隐式依赖。