[Rock-dev] Rock.cmake

Peter Soetens peter at thesourceworks.com
Mon Apr 18 17:08:51 CEST 2011


On Monday 18 April 2011 15:59:31 Sylvain Joyeux wrote:
> On 04/18/2011 03:07 PM, Peter Soetens wrote:
> > Part of this plan is also based on the 'openness' of the ros build
> > system: you don't need a file that describes your project layout or
> > version control settings. Just 'unzipping' a package in your
> > ROS_PACKAGE_PATH is enough to have it known and used by all tools and
> > other packages. The only file it requires is an os-dependencies file
> > that lists how to resolve these. So that's why we're looking into using
> > autoproj/orogen in such an 'open' system. autoproj controls part of the
> > packages, but they are located in a ROS_PACKAGE_PATH, such that whatever
> > autoproj/orogen installs/generates is picked up as well.
> 
> Just to clarify something: for that to work, every packages in rock
> would need to be using rosbuild (either directly or through a
> compatibility layer like what you did with useorocos), right ?

No. 

The use of rosbuild in the UseOrocos macros is actually not required, we just 
used it 'to be sure' *and* because it picks up the 'export cflags' in the 
manifest.xml file (a ros extension). Ie, it was the path of the least 
resistance. But rosbuild does not do any magic we can't do.

The only thing that 'rosmake' requires is a top-level Makefile with the 'all' 
target. It uses that file to rebuild the package if one of its dependencies 
changed (autoproj/build knows how to rebuild a given package, so does not need 
this, but does need the info in a different file anyway...).

So:
rosmake == autoproj (manage inter-project+OS dependencies and builds)
rosbuild  == autobuild (build a single package

rosmake and rosbuild are independent of each other. The latter is only a set 
of utility macros, like UseOrocos-RTT.cmake.

Peter


More information about the Rock-dev mailing list