DEPENDS and CATKIN_DEPENDS used to tell catkin need to pass your A program which dependency package to use find_package (...) to find your program package package B.
And just to be found in CMakeLists.txt in find_package () and catkin_package (), that is to say, catkin_package () is acting find_package () in.
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()
For example, suppose you find_package (Boost REQUIRED), and with a line of code in the header file you #include the installation. For a dependent on your own #include packages can use your header files, they need to include the include directory Boost in your include path (in fact, in visual c ++ #include the header file is not in the same way), also you need to connect the Boost library (with earlier comments). Because you have already exported in the header file (it is derived from the program #include do?) (Could it be that in visual c ++ #include is an operation, the next operation is to generate class CMakeLists.txt this file? ) the dependence, they should get from where you are dependent. That is, they no longer need find_package (Boost REQUIRED) (which is dependent on a package, which is dependent on the package need not be repeated declarations of its dependencies), because they are using to build your package, rather than directly using Boost.
Your package (dependent is a dependent or two? Seen from the back, should be dependent on a) Boost relies on the fact that is an implementation detail, so when some packets (one packet) by find_package (.. .) when looking for your package (two packages), they (a package) can be obtained indirectly dependent on the Boost. Let this mechanism is to work in your catkin_package (...) call added DEPENDS Boost parameter (in the secondary package) (plus DEPENDS Boost will be able to rely on the dependencies of dependencies). Implementation details are:
catkin will find_package (Boost) (acting on global)
Added to $ {your_pkg_LIBRARIES} $ {Boost_LIBRARIES} (acting on a package)
Add $ {Boost_INCLUDE_DIRS} to $ {your_pkg_INCLUDE_DIRS}. (Acting in the secondary package)
your_pkg_LIBRARIES should be using Boost package, combined with maintenance of the above should be a lot of variables for the operating environment of this package, than say x'm speaking of your_pkg_LIBRARIES.
We should note, catkin will find_package () tells you it's the exact package name, and then try _LIBRARIES and _INCLUDE_DIRS variables that package (to prove each library also has many variables still under UBUNTU environment). But find_package (...) in the form of variable results obtained is not always the case (in conjunction with the following, it should be said that the variable name is not fixed), because CMake does not enforce this (meaning of this statement should not be CMake enforce naming conventions?). For example, when find_package python package form find_package (PythonLibs REQUIRED) outcome variables are: PYTHON_INCLUDE_PATH (this is the value after the your_pkg_DIRS assignment, PYTHON_INDLUDE_PATH corresponds Boost_INCLUDE_DIRS, it should be noted that they naming convention is inconsistent if they are consistent then, PYTHON_INCLUDE_PATH should be called PYTHON_INCLUDE_DIRS).
find_package (OpenGL REQUIRED) outcome variable was OPENGL_INCLUDE_DIR. (This time naming rules would be consistent with the example of the Boost library added).
In addition to tag prefix becomes different (PythonLibs -> PYTHON), the suffix becomes non-standard (PYTHON_INCLUDE_PATH and OPENGL_INCLUDE_DIR vs * _INCLUDE_DIRS, there are three suffixes in this sentence, respectively, and PATH DIR and DIRS). In this case you need to use INCLUDE_DIRS option to pass variables include the header file directory to catkin_package () in (this variable means include dirs), empathy LIBRARIES option is also doing similar things.
CATKIN_DEPENDS DEPENDS options and options are very similar, but for CATKIN_DEDPENS, you can only place catkin package (that is, application packet roscreate-pkg created) in its list. Catkin will depend on the benefits of a single set of options that can make catkin perform some additional checks, then warn you what is wrong with the practice.
Finally, give a simple example CMakeLists.txt:
cmake_minimum_required(VERSION 2.8.3)
project(foo)
find_package(Boost REQUIRED COMPONENTS
system
thread
) Wuxi good ××× hospital http://www.zzch120.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
)
...
In this example you can see that I find_package (find_package (Boost REQUIRED COMPONENTS)) and passes it to catkin_package () is DEPENDS part (catkin_package (DEPENDS Boost)). Because it (catkin_package ()) generated is compatible CMake variables (variables consistent format ???).
find_package in CMakeLists.txt file (PythonLibs REQUIRED), but do not pass it to catkin_package (), because I did not include it in my head exposed to any file in the outside world. I find_package (OpenGL ...), because the variables are not compatible with CMake it generates, so I will pass it explicitly to catkin_package () LIBRARIES part of INCLUDE_DIRS and, (not a variable, direct assignment). Finally, I find_package (catkin ... rosconsole roscpp, and for internal use, but I could only use rosconsole in .c * file, so I do not pass it, so catkin_package () CATKIN_DEPENDS part of me just put roscpp .
Finally, a note, however, if a package is directly dependent on the use of terms such as Boost, then they should ensure that the display find it with find_package (...), and not by other packages implicitly depends on it. For this example, if the package foo Boost as dependencies derived, but also depends on the bar package foo, but also Boost internal use, then the bar is not displayed even in a case where the dependent Boost can normally compiled. But then foo may decide to reconstruct and remove the dependence on Boost, then the bar will not compile now, because it no longer has an implicit reliance on Boost to pass through foo.