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

Your projects are setup correctly (mostly), you just need to run catkin_make with no arguments.

First update foo:

cmake_minimum_required(VERSION 2.8.3)
project(foo)

find_package(catkin REQUIRED COMPONENTS foo_msgs)

catkin_package()

include_directories(include ${catkin_INCLUDE_DIRS})

add_executable(foo_node src/foo_node.cpp)
add_dependencies(foo_node foo_msgs_gencpp)

Then just execute catkin_make with no arguments.

I setup an example repository here:

https://github.com/wjwwood/catkin_demos/tree/ros_answers_52744

Your projects are setup correctly (mostly), you just need to run catkin_make with no arguments.

First update foo:

cmake_minimum_required(VERSION 2.8.3)
project(foo)

find_package(catkin REQUIRED COMPONENTS foo_msgs)

catkin_package()

include_directories(include ${catkin_INCLUDE_DIRS})

add_executable(foo_node src/foo_node.cpp)
add_dependencies(foo_node foo_msgs_gencpp)

Using add_dependencies(...) is by design or necessity, however you look at it, because we cannot know or assume that foo's targets (executables or libraries) use and therefore depend on the messages which are getting generated by foo_msgs.

Then just execute catkin_make with no arguments.

If you want to build foo_msgs explicitly (not the whole workspace) then as of pull request ros/catkin#352 you can do catkin_make --pkg foo_msgs.

Calling catkin_make foo_msgs is not sufficient because that is instructing catkin_make to invoke the foo_msgs make target which does not exist. tkruse's solution simply adds a foo_msgs target which depends on the foo_msgs_gencpp target, allowing it to be callable and causing the foo_msgs_gencpp target to be generated. This is not something we do by default because packages often define targets with the same name as the project which would immediately cause a conflict.

The only reliable way to build an entire package (including all of its targets) is to go to the package's build space and invoke make [all], which is what catkin_make --pkg does.

I setup an example repository here:

https://github.com/wjwwood/catkin_demos/tree/ros_answers_52744

click to hide/show revision 3
No.3 Revision

Your projects are setup correctly (mostly), you just need to run catkin_make with no arguments.

First update foo:

cmake_minimum_required(VERSION 2.8.3)
project(foo)

find_package(catkin REQUIRED COMPONENTS foo_msgs)

catkin_package()

include_directories(include ${catkin_INCLUDE_DIRS})

add_executable(foo_node src/foo_node.cpp)
add_dependencies(foo_node foo_msgs_gencpp)
foo_msgs_generate_messages_cpp)

Using add_dependencies(...) is by design or necessity, however you look at it, because we cannot know or assume that foo's targets (executables or libraries) use and therefore depend on the messages which are getting generated by foo_msgs.

Then just execute catkin_make with no arguments.

If you want to build foo_msgs explicitly (not the whole workspace) then as of pull request ros/catkin#352 you can do catkin_make --pkg foo_msgs.

Calling catkin_make foo_msgs is not sufficient because that is instructing catkin_make to invoke the foo_msgs make target which does not exist. tkruse's solution simply adds a foo_msgs target which depends on the foo_msgs_gencppfoo_msgs_generate_messages_cpp target, allowing it to be callable and causing the foo_msgs_gencppfoo_msgs_generate_messages_cpp target to be generated. This is not something we do by default because packages often define targets with the same name as the project which would immediately cause a conflict.

The only reliable way to build an entire package (including all of its targets) is to go to the package's build space and invoke make [all], which is what catkin_make --pkg does.

I setup an example repository here:

https://github.com/wjwwood/catkin_demos/tree/ros_answers_52744