About the functions of several commonly used commands in CMakeList.txt in the ROS package——————(2)

Table of contents

(5)catkin_package()

(6)add_library()   

(7)add_dependencies( []...)


Continuing from (1) Regarding the functions of several commonly used commands in CMakeList.txt in the ROS package——————(1)_u012057432’s blog-CSDN blog , the following are other related configuration commands, some are not necessary, but they are Very commonly used, but also very important.

(5)catkin_package()

If ROS package B depends on ROS package A, then in order for package B to use the find_package() instruction to find A normally and obtain the relevant variables of package A (header file path, library path, etc.), it needs to be in package A in advance. Use the Catkin_package() macro in CMakeList.txt to make relevant configurations. This command macro can "pass" the relevant information about A to the find_package() instruction of package B. In other words, the Catkin_package() macro of package A serves the find_package() of package B.

For the default writing template

catkin_package(
  INCLUDE_DIRS include
  LIBRARIES pose_estimation
  CATKIN_DEPENDS pcl_conversions pcl_ros roscpp sensor_msgs
  DEPENDS system_lib
)

in:

  • INCLUDE_DIRS include: If there is a header file folder defined in package A, the folder address will be passed to B as the variable A_INCLUDE_DIRS in B's camke process.
  • LIBRARIES pose_estimation: The address of the library file (pose_estimation) generated in package A is passed to B as the variable pose_estimation_LIBRARIES in B's camke process.
  • CATKIN_DEPENDS pcl_conversions pcl_ros roscpp sensor_msgs: Some catkin packages that package A depends on can make B recursively depend on them without having to manually depend on them in B again.
  • DEPENDS system_lib: Some non-catkin packages that package A depends on can make B recursively depend on them (recursively find their library paths, header file paths, etc.) without having to manually depend on them in B again.

(6)add_library()   

This command is mainly used to create library files yourself. It is usually placed before target_link_libraries. The specific command is

add_library(<name> [STATIC | SHARED | MODULE] [EXCLUDE_FROM_ALL] [source1] [source2] [...])

This command is used to make gcc generate a library file named <name> from the specified source file (the actual name generated will have different names according to the system platform. For example, in Linux, lib<name>.a will be generated to The beginning of lib tells the system that this is a library file), and the following [STATIC | SHARED | MODULE] means that you want to generate a "static library", "dynamic library", and "module library?" (This module library will not be statically linked, but It may be loaded dynamically through methods such as dlopen, I don’t understand this). If you don't explicitly mark which one it is, it will be based on the value of BUILD_SHARED_LIBS (itself a cmake flag variable, specifically used to specify the generation type of add_library), whether it is ON or OFF. ON means building a dynamic library, and OFF means Build static libraries. The value of BUILD_SHARED_LIBS is generally given when executing the cmake command. For example, when executing:

cmake -DBUILD_SHARED_LIBS=OFF ..

If the value of BUILD_SHARED_LIBS is not specified, the default is OFF. Therefore, when the [STATIC | SHARED | MODULE] parameter is not specified, the static library is built by default.

example:

### Build simple_grasping library
add_library(simple_grasping
  src/cloud_tools.cpp
  src/object_support_segmentation.cpp
  src/shape_extraction.cpp
  src/shape_grasp_planner.cpp
)

Above, the cpp file that does not contain the main function in its own src is built into a static library. What is reasonable and interesting is that this library can use the target_link_libraries instruction to link with its own cpp target file that contains the main function, so You can avoid writing a bunch of cpp specific names in add_executable.

A more complete example:

### 构建名为simple_grasping的静态库,此语句之后,gcc就会把它们编译成二进制文件
add_library(simple_grasping
  src/cloud_tools.cpp
  src/object_support_segmentation.cpp
  src/shape_extraction.cpp
  src/shape_grasp_planner.cpp
)
###把库的目标文件和外部库文件进行链接,这样才能构建出完整的库?
###刚试了一下,并不需要进行链接外部的库,因为它只是被用到了下面与basic_grasping_perception进行链###接,可以在后面一起链接
target_link_libraries(simple_grasping
  ${Boost_LIBRARIES}
  ${catkin_LIBRARIES}
  ${PCL_LIBRARIES}
)
### 自己的main目标文件,注意没有其他的cpp文件,而是用库代替了,很方便
add_executable(basic_grasping_perception src/basic_grasping_perception.cpp)
###看到,在这里把自己的simple_grasping库和外部的库,以及main目标文件进行了链接。
target_link_libraries(basic_grasping_perception
  simple_grasping
  ${Boost_LIBRARIES}
  ${catkin_LIBRARIES}
  ${PCL_LIBRARIES}
)

(7)add_dependencies(<target> [<target-dependency>]...)

This is generally placed after target_link_libraries. It mainly tells cmake that a top-level target (this target) depends on another top-level target (<target-dependency>) to ensure that the dependent <target-dependency> is built before this target. complete.

The so-called top-level target value is the target object created by the add_executable(), add_library() or add_custom_target() instruction. Generally speaking, it can be simply understood that this command is used to ensure that another self-written package B is built before this package A. .

Guess you like

Origin blog.csdn.net/u012057432/article/details/103353547