Closed meyerj closed 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...
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.
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
There are some other details that were removed when I removed rosbuild support in my fork, see the details here:
https://github.com/meyerj/rtt/commit/8d465b341005238a9dd6fbd03632d7619aca148e#commitcomment-3974459
https://github.com/meyerj/rtt/commit/8d465b341005238a9dd6fbd03632d7619aca148e#commitcomment-3974458
@meyerj I can make the changes, I;ll pull yours in and then re-add the stuff I removed. I'll close this issue when I'm done, if we still need to re-iterate, we can re-open it.
@jbohren As you want. I can also do it, but not before tomorrow afternoon. The rosbuild_support branch is really only a draft and some of my proposed changes here is still missing (e.g. write a pkg-config file in CATKIN_DEVEL_PREFIX). If you don't mind, perhaps it would be easiest if you give me push access to jhu-lcsr-forks so that we can work in the same repo? I would only commit stuff to the main branches that we agreed upon in the discussions.
@meyerj
@jbohren As you want. I can also do it, but not before tomorrow afternoon. The rosbuild_support branch is really only a draft and some of my proposed changes here is still missing (e.g. write a pkg-config file in CATKIN_DEVEL_PREFIX). If you don't mind, perhaps it would be easiest if you give me push access to jhu-lcsr-forks so that we can work in the same repo? I would only commit stuff to the main branches that we agreed upon in the discussions.
Yeah I can definitely give you access. Consider it done. I'm over here on US east coast time so I've got some time to work on it today (:
There are a lot of topics in this issue, some of them have to do with rtt_ros_integration, and others require changes in rtt, itself.
Most of rosbuild support was resurrected via the following commits (along with catkin support): https://github.com/jhu-lcsr-forks/rtt/compare/d607a06...3c47308?w=1
Then, orocos_use_package()
was split into orocos_use_package()
and orocos_find_package()
: https://github.com/jhu-lcsr-forks/rtt/commit/9236de4404e6ecfe1280a43a2128221593a904a7
Further discussion of modifications to the rtt package concerning catkin support should happen here: https://github.com/jhu-lcsr-forks/rtt/issues/4
This is a follow up of #8 as rosbuild support is not really within the original scope.
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:CMAKE_INSTALL_PREFIX
prefix and install it to${CMAKE_INSTALL_PREFIX}/lib/pkgconfg
(independently from ROS/catkin).CATKIN_DEVEL_PREFIX
is set, create a .pc file withCATKIN_DEVEL_PREFIX
prefix in${CATKIN_DEVEL_PREFIX}/lib/pkgconfig
.ROSBUILD_init_called
is set, create a .pc file withPROJECT_SOURCE_DIR
prefix in${PROJECT_SOURCE_DIR}/lib/pkgconfig
.Yes, I should have been clearer here. rosbuild support in my opinion includes:
orocos_component()
,orocos_library()
, ... should userosbuild_add_library()
if rosbuild is detected (based on theROSBUILD_init_called
variable?).find_package(rtt_roscomm)
and callros_generate_rtt_typekit()
andros_generate_rtt_service_proxies()
on rosbuild message packages. This replaces the formerrosbuild_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 thePKG_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 thePKG_CONFIG_PATH
. The real work is still done bypkg_search_module()
afterwards.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 ofpackage.xml
(or only if nopackage.xml
file exists). Recursive plugin dependencies could still be declared via<export><plugin_depend>...</plugin_depend></export>
if this is preferred.