rosbuild support - Githubissues

meyerj commented 11 years ago

This is a follow up of #8 as rosbuild support is not really within the original scope.

Right, we can do this, but part of the goal of all of this is to remove all of the catkin/ros-specific stuff from the Orocos upstream, aside from lightweight package.xml files. If we added the ${CATKIN_DEVEL_PREFIX} variable to the normal orocos_generate_package() macro, then that would involve putting catkin code into the Orocos upstream.

I would vote for not totally ban everything that has to do with ROS/catkin from upstream rtt, as long as no ROS libraries are used and there are no differences in the binaries. But to check if certain cmake variables are defined and to create additional files or use other default paths in the UseOROCOS-RTT macros would be okay if that makes life easier...

Concerning orocos_create_package(), I propose the following behavior:

Create a .pc with CMAKE_INSTALL_PREFIX prefix and install it to ${CMAKE_INSTALL_PREFIX}/lib/pkgconfg (independently from ROS/catkin).
If CATKIN_DEVEL_PREFIX is set, create a .pc file with CATKIN_DEVEL_PREFIX prefix in ${CATKIN_DEVEL_PREFIX}/lib/pkgconfig.
If ROSBUILD_init_called is set, create a .pc file with PROJECT_SOURCE_DIR prefix in ${PROJECT_SOURCE_DIR}/lib/pkgconfig.

I would like to keep rosbuild support if possible. The differences in the required cmake code and the rtt_ros service are not so big and it would be convenient for existing projects. It would be okay to require some changes in the manifests and in cmake, but I don't see a good reason to drop rosbuild support totally.

To be clear, you mean support for rosbuild packages to depend on catkin-based orocos packages, right?

Yes, I should have been clearer here. rosbuild support in my opinion includes:

All orocos/rtt_ros_integration packages are plain cmake or catkin. This is already the case thanks to your work.
rosbuild packages can find_package() and use orocos like any other cmake project. Orocos cmake macros orocos_component(), orocos_library(), ... should use rosbuild_add_library() if rosbuild is detected (based on the ROSBUILD_init_called variable?).
rosbuild packages can find_package(rtt_roscomm) and call ros_generate_rtt_typekit() and ros_generate_rtt_service_proxies() on rosbuild message packages. This replaces the former rosbuild_include(rtt_rosnode GenerateRTTtypekit) call.
orocos_use_package()/orocos_find_package() or any equivalent macro in package rtt_ros should use rospack to find the package and its dependencies and set the PKG_CONFIG_PATH environment variable for rosbuild packages found. For catkin or installed orocos packages we do not need that as their configuration files are already in the PKG_CONFIG_PATH. The real work is still done by pkg_search_module() afterwards.
The rtt_ros service should be able to import rosbuild packages.

2.-4. have already been implemented in the rosbuild_support branches of meyerj/rtt and meyerj/rtt_ros_integration (still testing). I did not look into 5. so far, but as the rtt_ros service already uses rospack to find packages it shouldn't be too complicated to also check if a manifest.xml file exists and use that one instead of package.xml (or only if no package.xml file exists). Recursive plugin dependencies could still be declared via <export><plugin_depend>...</plugin_depend></export> if this is preferred.

psoetens commented 11 years ago

Could you first confirm that: 1- Hydro has no rosbuild support so this proposal is only for Groovy or older ? 2- You don't want to call rosbuild_init() in your package's CMakeLists.xml file (so UseOrocos has to call it) ? 3- The UseOrocos logic now checks for the ROS_PACKAGE_PATH, if the current dir is in the ros package path and no catkin is detected, it's a rosbuild package...

meyerj commented 11 years ago

1- Hydro has no rosbuild support so this proposal is only for Groovy or older ?

I am talking about hydro. rosbuild support will not be dropped totally. The only thing is that it's not possible to release rosbuild packages any more on the ROS buildfarm (see Tully's anwer on ROS-users here: https://code.ros.org/lurker/attach/4@20130822.014202.19ef68d7.attach). In the current beta release building rosbuild packages from source works without problems. There are plans to drop rosbuild support in ROS indigo...

Of course it would be possible to also use and release the new catkin/hydro-devel version of Orocos/rtt_ros_integration in groovy. But as there will be changes at least in the cmake API this might not be a good idea. However, that's another topic.

2- You don't want to call rosbuild_init() in your package's CMakeLists.xml file (so UseOrocos has to call it) ?

No, it is the user's responsibility to call rosbuild_init() and decide if he wants to use rosbuild or not. UseOrocos should not decide anything.

3- The UseOrocos logic now checks for the ROS_PACKAGE_PATH, if the current dir is in the ros package path and no catkin is detected, it's a rosbuild package...

I am aware of this logic. My proposal is to just "capture" the rosbuild macros if they are defined. It's easy to check if either the ROSBUILD_init_called variable is true or if a macro has been defined:

if(COMMAND rosbuild_add_library)    # ... or if(ROSBUILD_init_called)
  rosbuild_add_library(...)
else()
  add_library(...)
endif()

If the user called rosbuild_init() before include(UseOROCOS-RTT.cmake) he will get rosbuild support. Otherwise he won't.

psoetens commented 11 years ago

On Thu, Aug 29, 2013 at 12:49 PM, Johannes Meyer notifications@github.comwrote:

1- Hydro has no rosbuild support so this proposal is only for Groovy or older ?

I am talking about hydro. rosbuild support will not be dropped totally. The only thing is that it's not possible to release rosbuild packages any more on the ROS buildfarm (see Tully's anwer on ROS-users here: https://code.ros.org/lurker/attach/4@20130822.014202.19ef68d7.attach). In the current beta release building rosbuild packages from source works without problems. There are plans to drop rosbuild support in ROS indigo...

Of course it would be possible to also use and release the new catkin/hydro-devel version of Orocos/rtt_ros_integration in groovy. But as there will be changes at least in the cmake API this might not be a good idea. However, that's another topic.

Hmm, yes, I was confused. This is only '2.7' + Hydro.

2- You don't want to call rosbuild_init() in your package's CMakeLists.xml file (so UseOrocos has to call it) ?

No, it is the user's responsibility to call rosbuild_init() and decide if he wants to use rosbuild or not. UseOrocos should not decide anything.

3- The UseOrocos logic now checks for the ROS_PACKAGE_PATH, if the current dir is in the ros package path and no catkin is detected, it's a rosbuild package...

I am aware of this logic. My proposal is to just "capture" the rosbuild macros if they are defined. It's easy to check if either the ROSBUILD_init_called variable is true or if a macro has been defined:

if(COMMAND rosbuild_add_library) # ... or if(ROSBUILD_init_called) rosbuild_add_library(...) else() add_library(...) endif()

If the user called rosbuild_init() before include(UseOROCOS-RTT.cmake) he will get rosbuild support. Otherwise he won't.

Fine for me.

Peter