[ros-users] resolving open REP-0122 issues

Wed Jul 25 14:24:37 UTC 2012

Tully,

Another clear and very informative message on an important and complex
topic. Thanks for making WG look good!

Steve
On Jul 25, 2012 6:59 AM, "Tully Foote" <tfoote at willowgarage.com> wrote:

> Hi All,
>
> I'd like to take a step back from the current discussion because I feel
> that there are several somewhat independent issues being talked without
> separation.
>
> Of the things being discussed at the moment I have identified the
> following 4 issues.  First is how are dependency flags passed to new code.
> Second is what is the FHS layout.  Third is how do we deal with resources.
> And 4th is an issue of modularity and code portability/namespacing.
>
> In the design of the new system we've sought to keep the usability of the
> ROS buildsystem while leveraging as much of the standard infrastructure as
> possible.
>
> For setting cflags and lflags it is standard to do this in your
> CMakeLists.txt  You can set what flags your cmake component exports in that
> component.  And then you use the CMake Find components which will pass
> those things to you automatically.  This means that people no longer need
> to learn a new buildsystem to us ROS, they can just use standard CMake.
>     It also means that we no longer have to maintain
> the equivalent functionality, which is already built into CMake. (There are
> other options we looked at too like pkg-config)  However, by building
> catkin on top of CMake we are able to provide much of the niceties of the
> ROS build system where you can overlay working copy on top of installed
> systems and you can develop and test in build space without requiring
> installation to test.
>
> With the FHS layout we are again working toward becoming more standard.  I
> believe this is much less controversial, though there's some debate about
> the exact layout.  The one thing I would like to point out is that makes
> the other requirements much more complicated, especially the capability to
> do overlays.
>
> We have always espoused writing libraries which are useable outside of ROS
> and then writing ROS wrappers.  By maintaining the pure CMake find modules
> infrastructure, we have reached the point that ROS packages when installed
> can be used by non-ROS packaged systems.
>
> As we go along this line part of what we are doing is narrowing the
> difference is a ROS package and what is a standard software package. Part
> of the restructuring of the core ROS dependencies which has gone along with
> this has been to cleanly separate the ROS message generation and the ROS
> communication infrastructure.  This now allows packages to depend on the
> message datatypes without incuring the cost of depending on the runtime
> requirements.
>
> We are also responding to a trend we have been watching where we are
> releasing more and more unary stacks.  Back in the day when we first added
> the concept of stacks many people asked why we had both stacks and
> packages.  Jack has relatively concisely stated the primary benefits of
> separating the interface unit and the release unit if the release unit
> contains multiple interface units.  However if we continue the trend toward
> releasing unary stacks this will not be a problem.  The biggest thing that
> we need to do for this is to make the release process easier. (Which has
> been addressed separately with the bloom package)
>       One of the primary motivators for releasing stacks which contained
> multiple packages was that we were getting too many packages to keep track
> of easily.  By organizing into stacks we were able to decrease the burden
> of understanding the dependency tree by decreasing the number of elements
> in the tree.  Unfortunately as we keep growing this has become a two fold
> issue.  First we now have enough stacks that we have the same problem as we
> had before with the packages. And secondly, by bundling packages into the
> same release we also bundle their dependencies.  As such we often end up
> with significantly more dependencies than might be optimal.  (For example
> take one of my stacks geometry, it has dependencies on bullet, eigen, and
> kdl to provide convenient converter functions for them, despite only
> needing bullet as a core dependency. In packaging it we've chosen to
> maintain that grouping for more user friendly operation, but many power
> users complain rightlfully that it's significantly bloated.  ) Thus as the
> pressure to not bundle dependencies is up and if we can ease the challenge
> of releasing the pressure to keep the number of release units down is
> lower.  Also from experience, large stacks are a pain to maintain because
> the have software inside with very different timelines, and consequently
> you have to try to shoehorn them into the same timeline to be able to
> release.
>
> The issue of ease of sharing is also a good point. We have many
> repositories which have just random unreleased packages which right now is
> relatively easy to grab and add to your system from source.  We should make
> sure to address this use case.  When actually doing releases with proper
> versioning having one release unit per DVCS makes the maintainer's life
> easier.  However, it's not required, and we can  make sure to keep it easy
> for a researcher to just have a flat repo with many "stacks" in it.
>
> Lastly is the issue of resources (ala launch files, meshes, etc)  With
> some of our python module development we have been successfully
> experimenting with using python's resource finding libraries and
> setuptools.  And we have been discussing creating a rosfind tool(executable
> and native library) for finding resources.  This would be the equivilant of
> 'rospack find' but implemented to work in the new environment, and support
> cross-compiling better.  And as I mentioned in the FHS paragraph this is
> one of the complicating cases.  Since we want to follow FHS we need to
> explicitly declare what we want to install, and what type of resource it
> is.  Standard files, such as libraries, headers, and python source
> automatically go to the right place.  However non standard files such as
> meshes, launch files etc are what need to be declared to support the
> install target.
>
> I hope this helps get a bit of perspective on what we've been working
> toward.  We are coming up on the freeze, however this discussion and
> features are important enought that we can also consider changing the
> deadline.  In the last release we had a dual push first to release Fuerte
> and then to release Precise support.  Pushing it back to be syncronized
> with Ubuntu's release could allow us to avoid the double push and do it at
> the same time.  (This is much better as you only need to iterate through
> the whole ecosystem once.  )
>
> Tully
>
> On Wed, Jul 25, 2012 at 4:18 AM, 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
>>
>
>
>
> --
> Tully Foote
> tfoote at willowgarage.com
> (650) 475-2827
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120725/e0e84d5d/attachment-0004.html>