On Wed, Jul 25, 2012 at 6:07 AM, Jack O'Quin <jack.oquin@gmail.com> wrote:
On Tue, Jul 24, 2012 at 7:01 PM, Dirk Thomas <dthomas@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@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