[ros-users] resolving open REP-0122 issues

Daniel Stonier d.stonier at gmail.com
Wed Jul 25 14:56:41 UTC 2012

Interesting thread!

I just browsed through its entirety. There seems to be a fair bit of
anxiety around catkin. I've been using catkin (formerly rosbuild2) for over
a year now - for cross compiling with arm compilers and development with
window's msvc. It's definitely a sea change in the way we build things in
RoS, but I believe the potential for doing things with catkin is enormous.
It really does free us from alot of constraints.

With regards to what we've come to value from the old system...

I think rather than trying to hang on to what was there, a better way to
approach the problem is to identify what we valued and proceed to work out
how to retain that value in catkin. Catkin can handle most (all?) of the
issues discussed above and for some issues there are several ways to do it.
To actually envisage how without a really good understanding of how the
cmake-python brew works is difficult. Let's throw in the items we feel are
important from the old build system, and let the catkin devs explain in
more detail or find a way to make things happen.

Re the stack/package differences. I can understand where Dirk is coming
from. Mechanically, the idea of a package is starting to become entirely
redundant within the build system. Package based namespacing - it would be
very easy to informally construct the same level of namespacing yourself,
or write some catkin logic to enforce some structure formally.
For dependencies - actually cmake does a far more efficient job of chaining
compiles via tracking of individual targets. It will only compile that
which you need and no more. Packages will tend to do alot more than what
you actually need. For non-code packages, I'm already finding ways to do
things the catkin way, yet achieve the same purpose. I could go on...but
the point is there - is the last vestige of the ros package just a human

Negatives about catkin...the only one that I can think of is that people
will have to know more cmake than they had to previously. Which doesn't
actually bother me greatly ;)


On 25 July 2012 20:18, Lorenz Mösenlechner <moesenle at in.tum.de> wrote:

> On Wed, Jul 25, 2012 at 1:00 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:
> > On Wed, Jul 25, 2012 at 4:03 AM, Lorenz Mösenlechner <moesenle at in.tum.de>
> wrote:
> >> In addition, I don't think that it is possible to convert all ros
> >> packages to catkin. Catkin is all about building but what about the
> >> packages that don't contain code? There are a lot of packages out
> >> there that contain only launch files and dependencies to build
> >> everything that is necessary to start these launch files. The most
> >> prominent examples would be pr2_bringup or pr2_gazebo. I don't really
> >> see how that is possible in a catkinized world.
> >
> > Those packages will have to be converted, too, because the launch
> > scripts will need to be installed somewhere. In that sense, XML files
> > *are* code.
> That is true.  But it's not about installing launch files but about
> managing dependencies and building everything that is necessary.
> At the moment, I guess most people have a lot of packages in a
> repository, not necessarily organized in stacks and possibly with some
> packages being broken. In particular, some of the packages are there
> only for specifying dependencies that are required to run something,
> e.g. for bringing up the robot. With rosmake, getting everything built
> that is required for running the robot is easy. With catkin, I would
> either need to build everything in that repo which might not work due
> to broken packages  or I would need to create something like a build
> workspace that symlinks only the packages I want to build. Both
> solutions would require some manual work.
> I think one reason for the great success of ros was that it made it
> really easy to use other people's code and get the dependencies
> resolved with just one call to rosmake. With catkin, the user needs to
> be more organized and building something just requires more knowledge
> and more work.
> Lorenz
> --
> Lorenz Mösenlechner            | moesenle at in.tum.de
> Technische Universität München | Karlstraße 45
> 80335 München                  | Germany
> http://ias.cs.tum.edu/         | Tel: +49 (89) 289-26910
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin R&D: http://rnd.yujinrobot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120725/db60f425/attachment-0004.html>

More information about the ros-users mailing list