[ros-users] A cross-compiling repository

Daniel Stonier d.stonier at gmail.com
Thu Aug 5 06:31:29 UTC 2010


On 5 August 2010 07:22, Cedric Pradalier <cedric.pradalier at mavt.ethz.ch>wrote:

> 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
>
>
Us also, for our intel atoms - I was using a hand made system and then a
crossdev built system, but did some testing and for control stuff at least,
the stripped down ubuntu was just as fast. It's only if you put too many
debs inbetween the baseline and your control programs that you start
noticing a non-optimised slowdown. But if you compile/optimise the important
things inbetween, it's still fast and the debs give you easy access to all
the tools (which don't need to be optimised) you need.

You only get in trouble when the distro doesn't have a repo for your core -
I think ubuntu only supports certain flavours of arm cores for instance.



> 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
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin Robot: http://www.yujinrobot.com/
Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100805/f87e4d28/attachment-0003.html>


More information about the ros-users mailing list