Hi Daniel,

I guess I should start by saying that as a former OpenEmbedded (OE)
developer I may be somewhat biased but I thought I'd chime in with a few
thoughts anyway.

On Wed, 2010-08-04 at 23:11 +0900, Daniel Stonier wrote:
> This is targeted at anyone who is either working with a fully
> cross-compiled ros or simply using it as a convenient build
> environment to do embedded programming with toolchains.

The risk I see with this approach is that you will inevitably end up
replicating a lot of work that has gone into existing cross-compilation
environments. One of the things that I believe make ROS beautiful is
that, despite its name, it's not an operating system. It sits on top of
any (more or less) supported operating system providing additional
services where necessary and leveraging existing facilities where
possible.

As far as the build environment is concerned, the interface between ROS
and the OS is the part of rosdep that translates dependencies into
native package names and calls the OS-provided package management system
to install those. I think it would be ideal if the cross-compilation use
case could be covered by similar means. This is particularly important
since the complexity of a cross-compilation environment tends to grow
exponentially with the number of targets supported.

[I'll focus on OE now simply because it's easiest for me to judge the
feasibility of this approach with OE.]

The way I think this could work with OE is, roughly, as follows:

1. Set up OE and ROS for the desired target in a well-defined matter,
   i.e. such that paths follow a certain, predictable, pattern. This
   could be scripted or even GUI-driven and is required such that OE can
   be invoked from ROS tools (and possibly vice-versa).
2. Export relevant variables (paths, compilers flags, etc.) from OE as a
   cmake toolchain description file and instruct ROS to use that.
3. Rely on rosdep to call bitbake (the OE build tool) to build
   system-dependencies (the toolchain and any packages already present 
   in OE such as boost/apr/etc.) and install them in the cross
   environment. Otherwise use rosmake as usual.
4. To build ROS packages (.deb, .ipk, .opk, etc.) for the target,
   rosmake (or some other tool) would generate a package description
   file (.bb) for OE, mainly consisting of the exported dependencies, a
   call to rosmake and information on where to find 
   executables/libraries built by rosmake, and again invoke bitbake.
5. Root filesystem or image creation would be left to OE. The only thing
   OE needs to know is a list of the packages built in 4.

Obviously, there are still some details to be worked out but the overall
approach should keep the amount of cross-compilation specific code in
ROS to a minimum and instantly allow people to run ROS on any
OE-supported target (With vendors like Gumstix officially supporting OE
there are quite a few of these nowadays). 

Cheers,

Rene

-- 
------------------------------------------------------------
Dipl.-Inf. René Wagner                     Junior Researcher
DFKI Bremen                           Enrique-Schmidt-Str. 5
Safe and Secure Cognitive Systems             D-28359 Bremen

Phone: (+49) 421-218-64224       Fax: (+49) 421-218-98-64224
Web: http://www.informatik.uni-bremen.de/agebv/en/ReneWagner
--- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Deutsches Forschungszentrum für Künstliche Intelligenz  GmbH
Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern

Geschäftsführung:
   Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
                                          Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
                                Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern                          HRB 2313
------------------------------------------------------------