关于catkin_make xbo_face_msgs

可以catkin_make xbo_face_msgs_gencpp   单独编译生成

可以作为依莱库在后台生成。 http://answers.ros.org/question/52744/how-to-specify-dependencies-with-foo_msgs-catkin-packages/

How to specify dependencies with "foo_msgs" catkin packages

• catkin
• messages
• services

asked Jan 18 '13

cdellin
352 ●7 ●13 ●18

updated Feb 7 '13

Say I have two catkin packages, foo and foo_msgs, in my workspace. Here's how I currently have them set up:

project(foo_msgs)
find_package(catkin REQUIRED COMPONENTS message_generation)
add_message_files(
  DIRECTORY msg
  FILES foomsg.msg
)
generate_messages()
catkin_package(CATKIN_DEPENDS message_runtime)

project(foo)
find_package(catkin REQUIRED COMPONENTS foo_msgs)
catkin_package()
include_directories(include ${catkin_INCLUDE_DIRS})
add_executable(foo foo.cpp)

I find that if I catkin_make foo, the message isn't generated. Indeed, catkin_make foo_msgs is a no-op. catkin_make foo_msgs_gencpp works, however. In order to get foo to build correctly, I must add the following line to its CMakeLists.txt:

add_dependencies(foo foo_msgs_gencpp)

Is this by design? I'd expect that building the package foo_msgs would automatically generate all its messages. Is there a way to make that happen?

Edit: I've approved WilliamWoodall's answer, although KruseT's was just as useful. (I also added the include_directories() line to foo's CMakeLists.txt, which I initially forgot.)

It turns out my solution is correct; the foo_msgs_gencpp auto-target should be added as a dependency of the foo target. Note that there is some disagreement about whether a different solution should be supported by catkin; KruseT started a discussion on the topic here.

Since this type of explicit dependency auto-target (_gencpp and _genpy) is necessary for using ROS messages/actions/services in any executable, library, or script, I think it should be better documented (I found no reference to it in catkin/migrating_from_rosbuild). KruseT opened a related rosdistro issue here.

add a comment

3 answers

Sort by » oldest newest most voted

10

answered Feb 6 '13

WilliamWoodall
1486 ●12 ●12 ●22

updated Feb 28 '14

William
10401 ●57 ●109 ●191 http://wjwwood.io/

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_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_generate_messages_cpp target, allowing it to be callable and causing the foo_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_dem...

link

Comments

1

Hi WilliamWoodall, this is very helpful! Clearly the _gencpp dependency needs to go somewhere explicitly. You list it in foo's CMakeLists file. In that case, if foo_msgs is already installed (so catkin is only building foo), will the foo_msgs_gencpp dependency be correctly resolved by catkin?

cdellin  (Feb 6 '13)

1

Yes, CMake will ignore targets which are not defined, you could add add_dependencies(foo_node bar_does_not_exist) and it will build with no warnings.

WilliamWoodall  (Feb 6 '13)

Great! This is my favorite solution, since it doesn't introduce new targets (foo_msgs), and explicitly encodes the dependency between the foo (binary) target and the generated cpp messages.

cdellin  (Feb 7 '13)

Also, I want to stress about catkin_make arguments: (a) sometimes it is useful to build only particular targets (yes, targets, not packages), and (b) running catkin_make with no arguments doesn't help here; the _gencpp target is still required to ensure targets are built in the correct order.

cdellin  (Feb 7 '13)

(a) building specific target is already supported by "catkin_make", any argument without a special meaning is passed straight forward to "make", see "catkin_make --help" for details.

Dirk Thomas  (Feb 7 '13)

Hi Dirk! I understand this, I just wanted to correct the answer. I believe that WilliamWoodall's assertion that "running catkin_make with no arguments" would somehow fix my problem is incorrect.

cdellin  (Feb 7 '13)

add a comment

11

answered Aug 29 '13

kalakris
469 ●3 ●5 ●7 http://www-clmc.usc.ed...

updated Aug 29 '13

I believe the modern way of doing this is to add a dependency on ${catkin_EXPORTED_TARGETS}, as specified on this documentation page. It should look something like this:

find_package(catkin REQUIRED COMPONENTS foo_msgs)

add_dependencies(your_program ${catkin_EXPORTED_TARGETS})
add_dependencies(your_library ${catkin_EXPORTED_TARGETS})

link

Comments

You should check that `${catkin_EXPORTED_TARGETS}` is set to something before passing it to `add_dependencies(...)`.

William  (Aug 29 '13)

https://gist.github.com/wjwwood-snippets/5979727

William  (Aug 29 '13)

Doesn't the fix for this issue make this check redundant? https://github.com/ros/catkin/issues/453

kalakris  (Aug 29 '13)

Ah yes, I forgot we added that.

William  (Aug 29 '13)

2

The documentation link above is broken. The page can be found here.

Neil Traft  (Aug 8 '14)

add a comment

2

answered Jan 18 '13

KruseT
7313 ●35 ●81 ●142

updated Feb 7 '13

catkin_make with an argument just passes that argument to make. That a make target for the package exists is more by chance than design, I'd guess it is added by cmake for each subfolder (but not with nested folders). Maybe you can open a ticket on github to add the feature of a dedicated target to make. However a small problem exists, frequently a package named foo defines an executable named foo, so the target names overlap each other. Not sure whether any clean solution is possible. At least it wont be straightforward.

What you can do to cause "make foo_msgs" not be a noop is in package foo_msg, add a dependency like this:

add_custom_target(${PROJECT_NAME} DEPENDS ${PROJECT_NAME}_gencpp)

which is equivalent to

# add_custom_target(foo_msgs DEPENDS foo_msgs_gencpp)

but easier for copy&paste

[Update3: this is wrong:

Update: add_dependencies is definitely the wrong way to go, the way you use it (in foo, add dependency to foomsg). add_dependency should never cross catkin project boundaries. For you it only works coincidentally (because catkin cheats cmake conventions), it will break build in other cases or when building the projects in isolation.]

Update3: So it seems that indeed currently, calling add_dependencies accross package boundaries it currently the only recommendable way to achieve that the headers generated by foo_msg exist before they are being consumed by a target in foo.

We'll discuss this in the buildsystem SIG and maybe there will be a cleaner solution in the future.Discussion here: https://groups.google.com/d/topic/ros-sig-buildsystem/dvVO5QCHBLM/discussion

link

Comments

Ok, so the add_dependencies(foo foo_msgs_gencpp) solution is the right way to go?

cdellin  (Jan 18 '13)

Apologies kruset, I'm still confused. What exactly should I add to my CMakeLists file(s) for this example? I haven't found anything but the _gencpp dependency (across catkin project boundaries) to work.

cdellin  (Feb 6 '13)

There is no reason to call catkin_make with arguments... You are not telling catkin_make what packages you want to build you are just passing targets to make, and the project target and executable/library targets can overlap. It is better to just invoke catkin_make with no arguments.

WilliamWoodall  (Feb 6 '13)

I partially agree and partiall disagree, WilliamWoodall. Yes, clearly the user of catkin should be aware that catkin_make targets correspond directly with executable/library targets. I've found it very useful to only make/remake particular targets during development for compilation time purposes.

cdellin  (Feb 6 '13)

1

kruset, thanks for the clarification; this appears to be the best solution I've found. Perhaps it should go in a tutorial? Setting up this type of package structure (foo and foo_msgs) seems to be a very standard practice, and that I had such a hard time getting it to work properly is unfortunate.

cdellin  (Feb 6 '13)

The reason caktin_make foo_msgs is a no-op is that there is no make target for a package by default. In stead there is a Makefile for each time project(...) is called in CMake. The correct thing to do in order to build a package is to go to its location in the build folder and invoke make.

WilliamWoodall  (Feb 6 '13)

In my example, if I run: cd build/catkin_demos/foo_msgs && make all of the messages are generated. This is basically what catkin_make --pkg foo_msgs will do: https://github.com/ros/catkin/pull/352

WilliamWoodall  (Feb 6 '13)

Regarding documentation, I opened https://github.com/ros/rosdistro/issues/439.

KruseT  (Feb 7 '13)

see more comments