[ros-users] resolving open REP-0122 issues

[Jonathan Bohren]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120725/719d8088/attachment-0004.html>