On Wed, Jul 25, 2012 at 9:26 PM, Jonathan Bohren 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 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