Revision history [back]

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.

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.

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.

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.

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

# add_custom_target(foo_msgs DEPENDS foo_msgs_gencpp)

catkin_make foo foo_msg

catkin_make foo_msg_gencpp foo

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.

Update2: isolation.]

Update3: So what you can do 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

Then catkin_make foo_msg should not 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 no-op anymore. Then you can call

catkin_make foo foo_msg

To remake both.

It is else also valid for you to call

catkin_make foo_msg_gencpp foo

without any additions to CMakeLists.txt.

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.