On Tuesday 07 December 2010 12:03:52 Sylvain Joyeux wrote:
> On 12/07/2010 11:26 AM, Ruben Smits wrote:
> > > Here's the point: transports and ocl are the tip of the iceberg. The
> > >
> > > rock package library is designed so that people can cherry-pick what
> > >
> > > they want. There are 30+ packages. Think about branching and tagging
> >
> > that.
> >
> > Again, it feels like you are reinventing rosinstall.
>
> autoproj is an integrated "ros*". You might or might not like it, but
> that's what it is. From the very beginning, *autobuild* checked out code
> from multiple repositories, updated them, checked out new branches,
> allowed you to compare the state of your checkout with the remote
> repositories and so on. With multiple VCS. And multiple package types.
> *autobuild* exists since august 2005. Hardly "reinvented".
>
> *autobuild* already did dependency tracking and update/builds partial
> parts of your build tree.
>
> *autobuild* did not do stacks, *autoproj* did "stacks" (called package
> sets in autoproj speak)

Just to let you know, the following links are broken:

http://rock-robotics.org/api/autoproj/index.html
http://rock-robotics.org/api/autobuild/index.html

-R.

> What it did *not* do is get away from the accepted standard of
> installing software before you use it. And no rospack in cmake code.
> Because I did not like having the build system creep up in cmake/C++
> code. And the ROS-specific changes that went into oroGen templates
> recently "just to make them work in ros" makes me think that I was
> right. Reinventing dependency tracking and making the packages
> ROS-specific in the process is plain stupid. Even typekit's C++ code
> starts having ROS-specific bits. This makes me shudder.
>
> Moreover, to "reinvent" something, you need to have it in the first
> place. autobuild exists since mid-2005 (as far as VCS logs are
> concerned). autoproj predates the time I heard about ROS.
>
> About the automatic branching: the tool I am talking about was 10
> minutes of coding a script. Hardly a matter of reinventing something.

On Tuesday 07 December 2010 12:03:52 Sylvain Joyeux wrote:
> On 12/07/2010 11:26 AM, Ruben Smits wrote:
> > > Here's the point: transports and ocl are the tip of the iceberg. The
> > >
> > > rock package library is designed so that people can cherry-pick what
> > >
> > > they want. There are 30+ packages. Think about branching and tagging
> >
> > that.
> >
> > Again, it feels like you are reinventing rosinstall.
>
> autoproj is an integrated "ros*".

Just out of curiosity, what does the * stand for? make,pack,build,install or
all of them at the same time?

> You might or might not like it, but
> that's what it is. From the very beginning, *autobuild* checked out code
> from multiple repositories, updated them, checked out new branches,
> allowed you to compare the state of your checkout with the remote
> repositories and so on. With multiple VCS. And multiple package types.
> *autobuild* exists since august 2005. Hardly "reinvented".

I did not know autobuild was used behind the scene, then again I did not look
to much into autoproj's details. Hmm, maybe we should point the ros people to
autobuild and tell them they are reinventing stuff ;)

> *autobuild* already did dependency tracking and update/builds partial
> parts of your build tree.

So autobuild is more or less like rosmake "package" combined with rospack?

> *autobuild* did not do stacks, *autoproj* did "stacks" (called package
> sets in autoproj speak)

And autoproj is a combination of rosmake and rosinstall?

> What it did *not* do is get away from the accepted standard of
> installing software before you use it. And no rospack in cmake code.
> Because I did not like having the build system creep up in cmake/C++
> code.

I think you are right here, but for me the rosbuild cmake macros just made my
life al lot easier, instantly ... without a glitch, I can not say the same for
autoproj. And my resulting CMakeLists.txt files are really minimal. I do not
have to care about package dependencies myself in my CMakeLists, rosbuild will
make sure all the right flags are imported, without me forgetting one.

> Even typekit's C++ code
> starts having ROS-specific bits. This makes me shudder.

Hmm, can you point at an example of this??

The fact that I can just do import("packagename") in the deployer, and all my
the typekits that I depend on (wherever the are) are automatically loaded (and
only the ones I depend on) is fantastic. This made deployement of applications
dead-easy, from scripting and from XML.

> Moreover, to "reinvent" something, you need to have it in the first
> place. autobuild exists since mid-2005 (as far as VCS logs are
> concerned). autoproj predates the time I heard about ROS.

You're absolutely right here, but I heard about autobuild/proj after I heard
about rosbuild, so it is all about perception.

> About the automatic branching: the tool I am talking about was 10
> minutes of coding a script. Hardly a matter of reinventing something.

Just for the record, just because it is written in 10 minutes does not make it
not reinvented ;)

Ruben

On Tue, Dec 07, 2010 at 09:55:06AM +0100, Sylvain Joyeux wrote:
> On 12/06/2010 05:02 PM, Peter Soetens wrote:
> >>> corba stuff might break when other transports aren't playing nice in the
> >>> same repository. But can't we easily solve this using cmake logic which
> >>> only builds a transport if the dependencies are present ?
> >>
> >> And why should I "behind the scenes" get the LUA scripting just because
> >> lua-dev is installed ? mqueue transport ? Yarp transport ?
> >
> > This is/was actually quite common in the 'configure' days, where support for an
> > installed library was automatically added, not requireing the user to specify
> > tens of --enable-foo options.
> Yes. And that was already a bad behaviour in my opinion. And I already
> split LAAS packages when I wrote autobuild (autoproj's "guts") when the
> pieces were not belonging together.

BTW, why didn't you use robotpkg back then? Just curious.

Markus

On Tuesday 07 December 2010 09:55:06 Sylvain Joyeux wrote:
> On 12/06/2010 05:02 PM, Peter Soetens wrote:
> >>> corba stuff might break when other transports aren't playing nice in
> >>> the same repository. But can't we easily solve this using cmake logic
> >>> which only builds a transport if the dependencies are present ?
> >>
> >> And why should I "behind the scenes" get the LUA scripting just because
> >> lua-dev is installed ? mqueue transport ? Yarp transport ?
> >
> > This is/was actually quite common in the 'configure' days, where support
> > for an installed library was automatically added, not requireing the
> > user to specify tens of --enable-foo options.
>
> Yes. And that was already a bad behaviour in my opinion. And I already
> split LAAS packages when I wrote autobuild (autoproj's "guts") when the
> pieces were not belonging together.
>
> >> In the end, you get a lot of functionality that will not be used at all
> >> at the same time.
> >>
> >> Moreover, in both autoproj and rosbuild (I believe for this last one),
> >> functionality is selected by which packages are being built. By putting
> >> a lot of stuff in one package, you remove this ability. I.e. you require
> >> the user to start tuning the CMake options.
> >
> > rosbuild is a cmake macro wrapper. You mean 'rospack'. rospack can handle
> > this flawlessly, since one repository my contain multiple packages.
>
> True, forgot that in ros-XXX one package == one manifest.xml. For my
> information, can you tell ros-whatever to build one package and not the
> other (since they are *all* checked out) ? How ?

rosmake 'foo'
-> will use 'rospack find' to locate a directory 'foo' in the ROS_PACKAGE_PATH
which contains a manifest.xml file.
-> builds all dependencies of 'foo', according to manifest.xml
-> runs make in that directory, uses the one-line 'Makefile' Ruben has posted
before.

For example:
$ rosmake testros
[ rosmake ] Packages requested are: ['testros']
[ rosmake ] Logging to
directory/home/kaltan/.ros/rosmake/rosmake_output-20101207-100702
[ rosmake ] Expanded args ['testros'] to:
['testros']
[ rosmake ] Checking rosdeps compliance for packages testros. This may take a
few seconds.
Failed to find rosdep omniorb for package testros on OS:ubuntu version:10.04
Failed to find rosdep libreadline for package testros on OS:ubuntu
version:10.04
WARNING: Rosdeps [u'omniorb', u'libreadline'] could not be resolved
[ rosmake ] rosdep check passed all system dependencies in packages
[rosmake-0] Starting >>> rtt [ make ]
[rosmake-0] Finished <<< rtt No Makefile in package rtt
[rosmake-1] Starting >>> roslib [ make ]
[rosmake-1] Finished <<< roslib ROS_NOBUILD in package roslib
[rosmake-2] Starting >>> roslang [ make ]
[rosmake-2] Finished <<< roslang ROS_NOBUILD in package roslang
No Makefile in package roslang
[rosmake-3] Starting >>> xmlrpcpp [ make ]
[rosmake-3] Finished <<< xmlrpcpp ROS_NOBUILD in package xmlrpcpp
[rosmake-0] Starting >>> ocl [ make ]
[rosmake-1] Starting >>> rosconsole [ make ]
[rosmake-0] Finished <<< ocl No Makefile in package ocl
[rosmake-1] Finished <<< rosconsole ROS_NOBUILD in package rosconsole
[rosmake-1] Starting >>> std_msgs [ make ]
[rosmake-4] Starting >>> roscpp [ make ]
[rosmake-4] Finished <<< roscpp ROS_NOBUILD in package roscpp
[rosmake-1] Finished <<< std_msgs ROS_NOBUILD in package std_msgs
[rosmake-4] Starting >>> testros [ make ]
[rosmake-3] Starting >>> rosout [ make ]
[rosmake-3] Finished <<< rosout ROS_NOBUILD in package rosout
[rosmake-4] Finished <<< testros [PASS] [ 16.53 seconds ]
[ rosmake ] Results:
[ rosmake ] Built 12 packages with 0 failures.
[ rosmake ] Summary output to directory
[ rosmake ] /home/kaltan/.ros/rosmake/rosmake_output-20101207-100702

Since ROS was pre-built on my system, it contained the ROS_NOBUILD tag files,
which made it skip 'common dependencies' immediately.

>
> In any case, while autoproj kind-of support this, it is mostly expected
> that one package == one repo

So this limitation is an issue.

>
> Another thing: what is the actual point of keeping them in one
> repository if they are, anyway, different cmake packages ...

In ROS-speak, they are called 'stacks'. A stack is a logical group of
packages, that are always released together. These packages can be perfectly
independent or rely on each other, that's the stack's decision. For example,
Ruben released our orocos-toolchain git repositories as a single ROS stack.
Sometimes a package is only a few files (like xml or scripts). Splitting each
package in a git repository would be impractical. So I certainly want to be
able to provide multiple packages in one git repository.

I believe there are almost too many git repositories right now. For tagging,
branching and general 'on-branch-x.y' development, this gets slow, since I
have to make sure that each repository is on the right branch.

>
> >> Yes, it can be done. Just mentioning that I find the OCL situation
> >> horrible -- which makes me avoid it completely as much as I can -- and
> >> I'd like to avoid having the same situation with the transports package.
> >
> > OCL is indeed one package. We are getting pretty close to 'packetizing'
> > ocl if we would want to.
>
> There's always a huge gap between "we can do it if we want to" and "it
> is done". You know that.

Well, I would at least keep them in the same repository. In my view OCL is
pretty thin and focused already.

Peter

On Mon, Dec 06, 2010 at 03:03:07PM +0100, Sylvain Joyeux wrote:
> On 12/06/2010 01:40 PM, Markus Klotzbuecher wrote:
> > On Mon, Dec 06, 2010 at 01:31:13PM +0100, Sylvain Joyeux wrote:
> >> On 12/06/2010 12:29 PM, Peter Soetens wrote:
> >>
> >>> You're probably worried that the
> >>> corba stuff might break when other transports aren't playing nice in the same
> >>> repository. But can't we easily solve this using cmake logic which only
> >>> builds a transport if the dependencies are present ?
> >> And why should I "behind the scenes" get the LUA scripting just because
> >
> > Please, it is "Lua" which means moon in portugese, not some acronym.
> All my most abject apologies ;-)
>
> /me does not like uppercase even for acronyms ...

You are forgiven this time...

:-)

Markus