Mailinglist Archive: opensuse-buildservice (162 mails)

< Previous Next >
Re: [opensuse-buildservice] [RFC] transparent cross compiliation support for OBS
  • From: Carsten Munk <carsten.munk@xxxxxxxxx>
  • Date: Thu, 19 Jan 2012 08:39:39 +0100
  • Message-id: <CAK=iLrkjjVjZZ_RkiKyOFRYBXYihdCHjMNrXZy9H-CRo-CDrog@mail.gmail.com>
19. jan. 2012 08.24 skrev Daniel Gollub <gollub@xxxxxxxxxxxxx>:
Hi,
Hi,

we currently plan to enable OBS with an additional cross-compilation feature.
Which is referred in the "Build Service Concept CrossDevelopment" [1] as Type
3:
"[...] the build system is modified so original source and binary packages can
be build and used in a repository ".

So instead of using QEMU to emulate a different architecture completely, we
want to make use of cross-compilation using the host toolchain.

Later: for executing tests or other "target"-binaries during the
%build/%install/%check there will be still the need to use QEMU - which
would be then a mix of Type 3 and Type 4.


We have not started yet any coding, just have done some rough concepts
and wanted to make our planned effort public to involve the community in
the design, to make sure everyone is happy with that effort and useful not
only for us.

I should probably have noted this before on this mailing list, but
I've been working on a cross compilation solution surrounding
Scratchbox2 (SB2) and OBS for some months now, with an actual working
solution. I haven't yet upstreamed it as we've spent time validating
the solution and cleaning it up, optimizing - it currently builds my
322 package Mer Core without a hitch or source changes to all
packages.

The patches are available on https://github.com/stskeeps and an
out-dated description page at http://wiki.merproject.org/wiki/SB2

Scratchbox2 (not really related to Scratchbox 1, as some might know)
is a flexible mapping engine. that you can use it to alter the
perception of file systems and ability to be choosing to execute other
binaries (such as X86 binaries instead of ARM), enabling quite
flexible and interesting new ways of cross compiling. It works without
binfmt_misc as well, tested both in kvm and chroot. And can accelerate
things like autoreconf, etc. And can even export the running of target
binaries to a native host through 'sbrsh'

What we do in our build patches, when SB2 is enabled (flagged by a
prjconf setting), is to seperate into a build target and a build root.
When SB2 isn't enabled, BUILD_TARGET == BUILD_ROOT.

The 'build' script then extracts dependencies noted as SB2install:
into the BUILD_ROOT and the rest into BUILD_TARGET. Currently the
solution is SB2 + QEMU + toolchain + x86 tools exported using
baselibs.conf, but it's sure that a more elegant solution could be
done.

It then proceeds to installing the target packages utilizing SB2 and
then executing the build, enabling flexible control of what we want to
accelerate.

I just briefly wanted to introduce this work, so let me know if you'd
like to know more. I'm personally planning on putting it into
production with actual images and devices running it over the next
weeks - I think your idea could even be done using our SB2-OBS
solution.

Reviews on my patches to build/obs/osc / constructive flames etc, most welcome.

BR
Carsten Munk
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References