>From what I've seen of catkin, it definitely seems a lot more powerful / scalable than the current rosbuild infrastructure. i think some of the things Dirk was throwing around just made it seem like a lot of current ROS semantics were going to just get thrown away. Here are two thoughts, though, and correct me if I have anything confused:<div>

<br></div><div>--------------------------------------------------------------------------------</div><div>1) Why don't we just call wet stacks "packages" </div><div><br></div><div>Under catkin, the granularity of compilation and distribution are the same. From what has been said, it sounds like "dry packages" will no longer be first-class entities, and instead, "wet stacks" will be the items named as build dependencies. What I don't understand, is why we're calling these stacks, and instead, why don't we just call them "packages" and do away with "stacks" as we currently know them.</div>

<div><br></div><div>As was said earlier, "dry stacks" have not shown to be a scalable solution. It seems "wet stacks" are more like "dry packages" than they are like "dry stacks." For both people new to ROS as well as current ROS users transitioning to Catkin, I think just calling them "packages" will be more intuitive than "stacks."</div>

<div><br></div><div><div>--------------------------------------------------------------------------------</div></div><div>2) Why can't using Catkin as a user be as simple as adding a <depend> tag to a manifest.xml?</div>

<div><br></div><div>Under catkin, users appear to be required to know more CMake programming, and less rosbuild manifest markup. I agree that it's better to use existing standards than to create and maintain new ones, but the rosbuild manifest.xml semantics are so very intuitive for people new to software development (read: fresh graduate students). What I'm describing is the notion of only having to declare which packages you're depending on, and all of their cflags and ldflags will be used when building all parts your code. I wouldn't expect it to be hard to make sure that Catkin provides a CMake API similar to the rosbuild <depend> tags, and this can be optional, allowing users to harness the full power of CMake if they choose. </div>

<div><br></div><div>Someone said earlier that using Catkin will require learning more CMake, and how that's a "good" thing. I'm not sure about that. I think the less people need to learn to get their code up and running, the better. If they find they need more flexibility then they still have all of CMake at their disposal.</div>

<div><br></div><div>-j</div>