The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
I'm not sure about the technical side, but I'd assume if that would have been easy it would have been done. Now on the philosophical side: Given that rosbuild and catkin need to be somehow compatible (otherwise all packages would have to switch at once) and assuming there is only time to implement one direction, then as it is this is the better alternative.
rosbuild can depend on catkin. This means whenever a package is catkinized it will still work with catkin (obviously) and it will continue to work with rosbuild or in other words: Going ahead in catkinizing never destroys anything.
The issue that you are facing is thus somewhat safe: You see now that it doesn't work from your dependencies, but you can still build your package in rosbuild. If it were the other way around then catkinizing a package might destroy some dependent packages that you even don't know about.
As to why not both ways work, I think that's mainly technical reasons.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
