[Rock-dev] Rock.cmake

[Peter Soetens]

On Friday 15 April 2011 16:33:16 Sylvain Joyeux wrote:
> First question: what do you mean by "build system" exactly here ?

This is the (predictable) scenario we have been observing the past months:

1. User uses bootstrap.sh
2. User wants to use ROS too
3. User has to re-install Orocos the ros way (.debs or ros install)
4. User wants to use rock
=> Does not compute

This scenario replays in different orders of 1-4. We want it to work in any 
order, and without the re-install steps. So I'm more referring to a 'single 
installation scenario from sources' than to a build system. For users using 
ubuntu packages, the problem is somewhat less, since we offer the debs from ROS 
'by default'.

That's why we're playing with these possible solutions:
- run bootstrap.sh in a ROS_ROOT/ROS_PACKAGE_PATH environment
-> does not work if user decides on ROS later on. Adding a bootstrapped orocos 
toolchain to a ROS_PACKAGE_PATH will lead to complete recompilation
- re-create all these scenarios in hudson in order to see what works and what 
doesn't.
-> This is wip, I'm currently testing bootstrap.sh when ROS_ROOT is set and 
when it's not set.
- provide all of bootstrap.sh (ruby, autoproj, libs, orogen etc) in a ros 
stack + Ubuntu packages. This now works stable, but this does not solve the 
problem for fedora, gentoo, debian users.

> 
> On 04/15/2011 04:03 PM, Peter Soetens wrote:
> > Could someone explain me why there is this parallel effort in
> > rock.cmake, which mirrors partially the UseOrocos-RTT.cmake macros ?
> 
> Because we don't want the rock libraries to be dependent on having RTT
> installed. In any way. Rock.cmake is not used, and is not going to be
> used, in orogen components. It is used only in the pure libraries that
> are shipped within Rock.

Ok, thanks for clarifying that file.

> 
> > The major feedback we got from the Orocos workshop was that there was
> > a need for a single build system, for both ros, rock and 'pure' orocos
> > users. What we're now looking at is that the Orocos toolchain can be
> > installed first, then ros and/or rock are installed and it will depend
> > on the application package if it's going to be a rosbuild ( no make
> > install ) or a standard build (with make install). ros would come with
> > a stack that integrates an existing orocos toolchain installation into
> > the ros eco system. rock would need to do the same, but orogen
> > generates packages that are buildable as a ros package, using the

This is a typo. 'but orogen *doesn't* generate packages that are buildable as 
a ros package'

> > UseOrocos-RTT.cmake macros. Furthermore, we could define a cmake macro
> > is_ros_package() that returns true if the current package is in a
> > ROS_PACKAGE_PATH instead of checking against the ROS_ROOT environment
> > variable (which might be accidentally set).
> 
> I don't understand this plan ... Could you explain a bit more ?
> 
> (by the way, orogen does *not* generate packages that are buildable as
> ros packages. *typegen* generates typekits that does. What you do with
> typegen and what rock does with orogen are greatly different approaches.

See typo. If we look at the plan without looking at any technical 
solution/problem, the plan is to install/run the ros/orocos/rock combo in any 
order, from sources. We want users to be able to expore the Orocos toolchain 
(on Linux) without any hickups, rebuilds or build system conflicts.

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.

> 
> > Looking at the rock.cmake file, it appears now orogen projects will
> > never work in a ros build environment.If you had used the
> > UseOrocos-RTT.cmake macros, the generated orogen code would have been
> > buildable by ROS users too.
> 
> Rock.cmake is not in use (and not going to be used) in orogen-generated
> packages. And UseOrocos-RTT.cmake is way too RTT specific to be used in
> libraries. And UseOrocos-RTT appeared way after orogen packages and I'm
> very open with someone doing a *working* migration of orogen templates
> to UseOrocos-RTT.cmake

Noted. We separated out the generation of the .pc file, so that orogen can 
generate it's own .pc without UseOrocos-RTT.cmake overwriting that one.

Having UseOrocos-RTT with orogen would also solidify these macros for broader 
use.

> 
> > I'm really looking for a solution here and not for an argument. If we
> > don't fix this soon, we'll loose (again) our momentum, and they will
> > not be moving to rock, but to ros. Guarantee you that.
> 
> Until we get to the point that orogen components can run on ROS, which
> the current ROS transport does *not* provide, I don't see how the build
> system has any influence in that respect. But anyway.

The ROS transport does not provide that, but we can have orocos components 
that speak both ROS and structs with typegen generated typekits. I understand 
this component can not be generated by orogen, since orogen must understand 
all types on all ports ? (unless we add the port in the user subclass?)

> 
> I'm (and I think I am also talking for quite a few rock developpers) all
> open for getting a set of cmake macros that are (1) not
> orocos-toolchain-RTT specific and (2) compatible with both "make
> install" and "ros-like" installations. (1) is provided by Rock.cmake (2)
> is not.
> Ah and (3) not trying to do too much, which is what the current
> UseOROCOS*.cmake does.

Hm.

> 
> The macros in Rock.cmake follow general guidelines for "make
> install-oriented stuff" and pkg-config-based dependency tracking. Plus a
> few sub-package-specific thing (as for instance, testsuite, vizkit
> plugins and stuff like that that are optional parts of the standard rock
> library package). Not much more than that.

The similarity to UseOrocos.cmake is strikingly though. The extra luggage on 
useorocos is that it also implements dependency tracking, automatic linking 
and .pc generation, all things which you do in orogen itself.

Peter