[ros-users] resolving open REP-0122 issues

Thibault Kruse kruset at in.tum.de
Thu Jul 26 11:40:05 UTC 2012


Hi, in reply to both Tully's and Daniel's posts:


On 07/25/2012 03:58 PM, Tully Foote wrote:
> 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.  ) 
+1 to this, or are we not voting?



On 07/25/2012 04:56 PM, Daniel Stonier wrote:
> 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. 

Here are my votes for my valued things map:

FHS compliance:          +1
Supporting out-of-source builds (install target):    +1
Derecommending in-source-build environments:       -1
CMake/python based build system:           +1
Dropping the concept of stacks vs. packages:   -1
Dropping support for manifest.xml based building and indexing:    -1
Dropping the stack/package relationship in installed layouts:   -1



The following is why I think so:


On 07/25/2012 03:58 PM, Tully Foote wrote:
> 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. [...]  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. [...] 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. 
You mention first the growing number of packages made it difficult to 
keep track,
and that now it becomes equally hard for stacks.

And unless I get this wrong,  the solution you suggest only solves the 
problem of
bloated releases, not the problem of keeping track.

The split into stacks and packages and the manifest.xml were a good way 
to declare
what belongs where in a machine readable way. That is a step up from 
having to read
documentation describing all that in prose, or even having to read 
through CMakelists.txt.

Manifests is what the wiki macros are based on, being able to tell which 
package depends on
which and is used by which, and what other packages are in the same stack.

It seems the effort of migrating from rosbuild to catkin is only 
measured in terms of
what it would need for each project to build again, not in terms of how 
much rework
the wiki, indexer and other documentation would need as a consequence.

On 07/25/2012 03:58 PM, Tully Foote wrote:
> 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.
It seems to me that the reason this is so easy now (easier than 
installing arbitrary
non-ROS software) is that until now we have in-source build processes as 
standard,
and a simplified way of setting up project builds (manifest.xml based).

Out-of-source builds means installing/uninstalling is more pain
than that and failed installs a common source of errors for
novice developers.

On 07/25/2012 04:56 PM, Daniel Stonier wrote:
>
> 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 ;)
Cmake does not make code portable, it only allows to do so, while in 
practice
it frequently produces stillborn projects that do not compile except on 
the one laptop
they were created on, for half a year or so. That's because frequently 
people refuse
to learn cmake, while still using it somehow.

Once you have to debug CMakelists.txts written by an intern, you might 
feel bothered.

I think it is good to move away from rosbuild, but to me catkin must do 
a better job of
maintaining the benefits rosbuild brought for those who benefited from them.

Also I believe the migration guide of catkin should do a better job of 
motivating
people to use catkin. Currently it reads to me like:
"More effort for you so that your software can be compiled on other systems
and be packaged easily. If you don't care about either, the bottom line 
is: More effort for you, yay."

It should read: "Same effort for you (no need to change docs, tutorials, 
move wiki pages, no need to
learn cmake and how to manage local installs), but it runs faster and 
more robustly, and provides
better support for you."

Saying here that catkin introduction means people will have to learn 
more is not a good marketing strategy.

cheers,
   Thibault



More information about the ros-users mailing list