19. jan. 2012 08.24 skrev Daniel Gollub
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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org