[ros-users] resolving open REP-0122 issues

Lorenz Mösenlechner moesenle at in.tum.de
Wed Jul 25 09:03:54 UTC 2012


In addition, I don't think that it is possible to convert all ros
packages to catkin. Catkin is all about building but what about the
packages that don't contain code? There are a lot of packages out
there that contain only launch files and dependencies to build
everything that is necessary to start these launch files. The most
prominent examples would be pr2_bringup or pr2_gazebo. I don't really
see how that is possible in a catkinized world.

Lorenz

On Wed, Jul 25, 2012 at 7:31 AM, Jonathan Bohren
<jonathan.bohren at gmail.com> wrote:
> On Wed, Jul 25, 2012 at 6:07 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:
>>
>> On Tue, Jul 24, 2012 at 7:01 PM, Dirk Thomas <dthomas at willowgarage.com>
>> wrote:
>> > On 24.07.2012 15:38, Jack O'Quin wrote:
>> >>
>> >> On Tue, Jul 24, 2012 at 5:15 PM, Dirk Thomas <dthomas at willowgarage.com>
>> >> wrote:
>> >>
>> >>> For the dry world all artifacts are deployed under the package name.
>> >>> In a wet-only world I would expect that all artifacts of a stack
>> >>> should
>> >>> reside under a folder named after the stack.
>> >>
>> >> Why do you want to change that?
>>
>> > It comes down to the question if the future catkin-only world will have
>> > anything like a package (and manifest.xml files).
>> > If argued yes:
>> > - what is it used for?
>> > - why is it needed (besides stacks)?
>>
>> In ROS, stacks are the unit of release and installation, very
>> important in the build system. Packages are the unit of interface
>> definition and inter-component dependencies. Moving a package from one
>> ROS stack to another is trivially easy. Moving an interface to a
>> different package affects *every* other program that depends on it.
>>
>> For example, ROS programs that depend on sensor_msgs/LaserScan do it like
>> this:
>>
>>  * #include <sensor_msgs/LaserScan.h>
>>  * from sensor_msgs.msg import LaserScan
>>
>> Every launch script executes nodes relative to their containing
>> packages. Messages frequently contain other messages defined by other
>> packages.
>>
>> There are about 4000 ROS packages listed on the wiki under "Browse
>> Software"; many more that are not indexed. Every one of them provides
>> interfaces relative to the package name and depends on core ROS
>> package interfaces. That includes the "wet" stacks and packages that
>> have already been ported to catkin.
>>
>> Your proposal implies that every single program must be modified in
>> Groovy to use common_msgs/LaserScan, instead. Surely that is not your
>> intent.
>
>
> Yeah, I'm really concerned about this too. I can understand re-writing build
> files, but as is clear from the last long ros-users thread, the community as
> a whole just doesn't have time for such a complete re-working of the ROS
> dependency semantics of every single package.
>
>>
>> > (Obviously my opinion is that packages a on-standard way - so for a
>> > CMake
>> > based buildsystem like catkin I would vote for not having a notion of
>> > packages for wet-only)
>> >
>> > If no, shouldn't the deployment folder than be renamed to be the stack
>> > name?
>> >
>> > Please think about how a catkin-only world should look like and reply
>> > your
>> > opinions - I am looking forward for any feedback!
>>
>> Catkin is not the world. The ROS repository federation is the world.
>> Catkin is a build system.
>
>
> Well put, Jack.
>
>>
>> I was assuming the catkin conversion would only affect build files.
>> You are proposing that every existing ROS source interface be changed.
>> Who would do all that work? And, why?
>
>
> I think the "why" is an important question. I understand Catkin calls CMake
> only once. But if you ask me, the number of times CMake gets invoked is
> really just about the lowest thing on my list of concerns when it comes to
> developing robotics software.
>
> Additionally, I just noticed this on the catkin migration guide
> (http://ros.org/doc/fuerte/api/catkin/html/rosbuild_migration.html):
>>
>> as a result: rosbuild implicitly adds compile and link flags based on
>> package dependency information; catkin requires you to add them explicitly
>
>
> I can't emphasize enough that I do not like the idea of this at all. One of
> the things that I _love_ about the rosbuild-manifest system is that I don't
> need to deal with compile and link flags of each dependency in the
> CMakeLists.txt of a given package. What's wrong with the implicit flags
> given by dependency info and the <export> tags?
>
> -j
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
Lorenz Mösenlechner            | moesenle at in.tum.de
Technische Universität München | Karlstraße 45
80335 München                  | Germany
http://ias.cs.tum.edu/         | Tel: +49 (89) 289-26910



More information about the ros-users mailing list