On Wed, Jul 25, 2012 at 9:26 PM, Jonathan Bohren
<jonathan.bohren@gmail.com> wrote:
> 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.
>
> 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.

This is my main concern with Catkin, as well. One of the great
benefits of rosmake is that it's stupidly, ostentatiously,
mind-blowingly, _simple_. It's not clear that it could be made any
simpler without losing major functionality.

Put another way: we ship documentation for 95% of the use cases for
rosmake _inside the CMakeLists.txt that you get for free when you
create a package_. (Minus the one sentence "put your dependencies in
manifest.xml.") That file fits on one page. I used rosmake for more
than a year before I learned a single thing about CMake, and without
ever reading a single page of real documentation. This is a
_profoundly_ rare (and awesome!) quality in any software system,
particularly a build tool, and we lose it at our peril.

It may easily be the case that Catkin could be made 95% as easy as
rosmake; I don't know. One good two-page howto could probably solve
this. (I haven't read the catkin docs; it may already be done!) The
important thing here is _this cannot be forgotten, or done badly_.

The ROS learning curve is already pretty steep. If the first step
becomes "go learn a build system", we've just made it a lot steeper. I
cannot believe that most of our users care, _at all_, which build tool
we use; they want one they don't have to think about. (Other than
ranting about "simplify whenever possible" on mailing lists, I
certainly don't care!) If Catkin makes the release team's life 90%
easier, and everybody else's life 5% harder, then it's a mistake,
period.

If it takes an extra thirty minutes to learn how to build ROS packages
("makes my life 0.1% harder"), and all of my builds are 10% faster?
Totally worth it!

    --M

--
Julian "Mac" Mason      mac@cs.duke.edu      www.cs.duke.edu/~mac

_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users