Hello,
just my 2 cents here, but I've worked with OE and with a stripped down
arm ubuntu (or debian for that matter), and I really enjoyed much more
the packet system of ubuntu. I really love to just be able to apt-get
install minicom or gdb, or a specific library.
For that, I vote for whatever cross-compiling that results in a nice
package management system.
Cheers
On 08/04/10 21:28, René Wagner wrote:
> 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
>
>
--
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp
(text/plain)