Bug in create_rtt_msgs (rtt_roscomm) when target to services
haianos opened this issue · comments
For some reason, there are visibility issues (maybe something wrong in the CMake macros..?) when generating a typekit for ROS services with create_rtt_msgs
tool.
Everything works fine if the target package contains .msg, but the issue affects only .srv
.
The generated package rtt_<target_pkg>
properly create the line ros_generate_rtt_service_proxies
, but in the user code of the component the header file is not found (eg, #include <target_pkg/MyService.h>
).
The issue is not on the component/package using the rtt_<target_pkg>
, since the same user code uses rtt_std_srvs
, which works just fine.
For now, the solution (apparently) is to include the dependency of "rosgraph_msgs" in the CMakeLists.txt as follows (but I can't explain why this solve the issue):
orocos_generate_package(
DEPENDS rosgraph_msgs
DEPENDS_TARGETS rtt_roscomm rtt_std_msgs
)
This dependency is mentioned in the rtt_std_srvs
(which works fine), but create_rtt_msgs
does not include it.
Possible actions:
- if the solution is correct, update the
create_rtt_msgs
by adding that dependency; - otherwise, the cause could be somewhere else...
NOTE: Tested on Ubuntu 16.04 LTS, v2.8.3 from sources (maybe the issue is already solved in latest version).
I think I had the same issue some time ago : #77
My colleague @JimmyDaSilva encountered this last month.
Same for jbohren/conman@b26d008
Yes, they might be related issues. In fact, I am not sure whether my solution is the solution, but it is possible that adding the rosgraph_msgs
dependency triggers something in the cmake compilation process that clean/fix the real issue...
I've double checked by removing the dependency from rosgraph_msgs
, and as I suspected 1) now it keeps compiling fine (so there is no real need for that dependency), but 2) that change triggered something in the compilation process (so it could be an useful hint)
The fix that I found was to add the package name in the catkin components (as in jbohren/conman@b26d008), could you try this ?
I tried, and it does not give any additional value (but right now, the issues is also fixed).
I think that "my fix" or that fix do not really solve the problem (because they are not necessary), but they do trigger something internal that makes everything compiling fine.
Could you please check whether #89 fixes the issue?
Thanks Johannes!
Checking the description, it sounds like a solution! However, I will be able to test it out only in 2 weeks...
Okay, I'll do a pre-release in kinetic including the patch. We can merge and close this issue after you confirmed that the patch works for you.