ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version
find_package(catkin REQUIRED COMPONENTS roscpp std_msgs)
find_package(catkin REQUIRED actionlib actionlib_msgs interactive_markers pcl_ros roscpp visualization_msgs arbotix_msgs moveit_core moveit_ros_planning_interface genmsgs)

Your problem is actually a CMake issue: you ask CMake to find_package(..) something called catkin twice.

First with COMPONENTS set to roscpp std_msgs, and then another time with a whole new list of things for catkin to look for.

That doesn't work, as CMake will store the result of the first find_package(catkin ..) in variables prefixed with catkin_..., and then the result of the second find_package(catkin ..) in variables prefixed with catkin_... But you already had variables prefixed with catkin_.., so the first ones are actually overwritten (and the results for roscpp std_msgs are lost).

In order to fix this, just append the list after COMPONENTS from your second find_package(..) call to the first.

find_package(catkin REQUIRED COMPONENTS roscpp std_msgs)
find_package(catkin REQUIRED actionlib actionlib_msgs interactive_markers pcl_ros roscpp visualization_msgs arbotix_msgs moveit_core moveit_ros_planning_interface genmsgs)

Your problem is actually a CMake issue: you ask CMake to find_package(..) something called catkin twice.

First with COMPONENTS set to roscpp std_msgs, and then another time with a whole new list of things for catkin CMake to look for.for (using the catkin find script).

That doesn't work, as CMake will store the result of the first find_package(catkin ..) in variables prefixed with catkin_..., and then the result of the second find_package(catkin ..) in variables prefixed with catkin_... But you already had variables prefixed with catkin_.., so the first ones are actually overwritten (and the results for roscpp std_msgs are lost).

In order to fix this, just append the list after COMPONENTS from your second find_package(..) call to the first.

tl;dr: find_package(..) calls do not accumulate results, but overwrite. You are calling find_package(catkin ..) twice, and only the results of the second invocation end up in catkin_INCLUDE_DIRS & friends. So info on roscpp (and std_mgs) is not actually stored.


find_package(catkin REQUIRED COMPONENTS roscpp std_msgs)
find_package(catkin REQUIRED actionlib actionlib_msgs interactive_markers pcl_ros roscpp visualization_msgs arbotix_msgs moveit_core moveit_ros_planning_interface genmsgs)

Your problem is actually a CMake issue: you ask CMake to find_package(..) something called catkin twice.

First with COMPONENTS set to roscpp std_msgs, and then another time with a whole new list of things for CMake to look for (using the catkin find script).

That doesn't work, as CMake will store the result of the first find_package(catkin ..) in variables prefixed with catkin_..., and then the result of the second find_package(catkin ..) in variables prefixed with catkin_... But you already had variables prefixed with catkin_.., so the first ones are actually overwritten (and the results for roscpp std_msgs are lost).

In order to fix this, just append the list after COMPONENTS from your second find_package(..) call to the first.

tl;dr: find_package(..) calls do not accumulate results, but overwrite. You are calling find_package(catkin ..) twice, and only the results of the second invocation end up in catkin_INCLUDE_DIRS & friends. So info on roscpp (and std_mgs) is not actually stored.


find_package(catkin REQUIRED COMPONENTS roscpp std_msgs)
find_package(catkin REQUIRED actionlib actionlib_msgs interactive_markers pcl_ros roscpp visualization_msgs arbotix_msgs moveit_core moveit_ros_planning_interface genmsgs)

Your problem is actually a CMake issue: you ask CMake to find_package(..) something called catkin twice.

First with COMPONENTS set to roscpp std_msgs, and then another time with a whole new list of things for CMake to look for (using the catkin find script). (or configure file)).

That doesn't work, as CMake will store the result of the first find_package(catkin ..) in variables prefixed with catkin_..., and then the result of the second find_package(catkin ..) in variables prefixed with catkin_... But you already had variables prefixed with catkin_.., so the first ones are actually overwritten (and the results for roscpp std_msgs are lost).

In order to fix this, just append the list after COMPONENTS from your second find_package(..) call to the first.

tl;dr: find_package(..) calls do not accumulate results, but overwrite. You are calling find_package(catkin ..) twice, and only the results of the second invocation end up in catkin_INCLUDE_DIRS & friends. So info on roscpp (and std_mgs) is not actually stored.


find_package(catkin REQUIRED COMPONENTS roscpp std_msgs)
find_package(catkin REQUIRED actionlib actionlib_msgs interactive_markers pcl_ros roscpp visualization_msgs arbotix_msgs moveit_core moveit_ros_planning_interface genmsgs)

Your problem is actually a CMake issue: you ask CMake to find_package(..) something called catkin twice.

First with COMPONENTS set to roscpp std_msgs, and then another time with a whole new list of things for CMake to look for (using the catkin find script (or configure file)).

That doesn't work, as CMake will store the result of the first find_package(catkin ..) in variables prefixed with catkin_..., and then the result of the second find_package(catkin ..) in variables prefixed with catkin_... But you already had variables prefixed with catkin_.., so the first ones are actually overwritten (and the results for roscpp std_msgs are lost).

In order to fix this, just append the list after COMPONENTS from your second find_package(..) call to the first.


Edit: also:

link_directories(${catkin_LIBRARY_DIRS} ${Boost_LIBRARY_DIRS} ${PCL_LIBRARY_DIRS})

This is almost never necessary in a (properly setup) catkin/CMake project. All entries in (catkin, Boost, PCL)_LIBRARIES are supposed to be absolute paths. Explicitly calling link_directories(..) can actually cause strange library resolving errors.