ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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.
2 | No.2 Revision |
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.
3 | No.3 Revision |
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.
4 | No.4 Revision |
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.
5 | No.5 Revision |
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.