2011/10/21 Jeremiah Foster <jeremiah.fos...@pelagicore.com>: > On Fri, Oct 21, 2011 at 3:05 PM, Carsten Munk <cars...@maemo.org> wrote: >> 2011/10/21 Lauri T. Aarnio <lauri.t.aar...@nokia.com>: >>> >>> On Oct 19, 2011, at 2:44 PM, ext Carsten Munk wrote: >>> >>> That is in fact what we did for an experimental SB2-based SDK for >>> Harmattan. There are even two perls, the ARM version and the x86 version >>> (both are known as /usr/bin/perl.) They don't have to have similar >>> configurations; the x86 side contains only selected tools and doesn't have >>> to be updated so often. >> >> Okay, so, let me elaborate - what I meant was - imagine this situation: >> >> 1) Source package build-depends on, random example, perl-SSLeay, which >> is a perl extension that's built with native code > > That is really a corner case. Most perl modules don't use XS (what you > refer to as "native code") and the perl-SSLeay module has been a > particular problem over the years because it has some pretty gnarly > dependencies. You won't see this problem with most of the perl modules > in MeeGo for example. <snip>
The case was generalized, using perl as an example - compiled code also exists in python extensions, ruby extensions, or other things people use for building within their packages these days. Generally: compiled code extensions for anything that ought to be accelerated by a X86 component as a use case > But you have to recognize that people are not going to just use your > packages, they're going to rebuild them. If they're not rebuilding > your packages, then your particular software or image is not > interesting for their particular problem. A reliance on a > overly-complicated toolchain that makes the current process hard to > reproduce and packages hard to rebuild on a new target or in a > different build system. Everyone says "use our tool!" but in fact in > open source you will find there are lots of tools, some of them as > good as yours. I'm not sure what you mean exactly, please elaborate. Besides that, this discussion is actually about discussing cross compilation approaches, alternatives, explaining each other's approaches :) For some cases, multiarch might be good too. With regards to 'hard to reproduce', two sides/things we've learnt from history: 1) Packages must not rely on being built inside a specific cross compilation environment This is what made Maemo packages so bloody hard to reproduce on top of Debian/Ubuntu - they relied on things Scratchbox did. In the OBS 'cross' approach we try to be as close as possible to as how an ARM machine would build the package. 2) MeeGo cross compilation was a nightmare to reproduce and copy to other OBS'es and get working properly, due to source packages not representing the needed contents / links between packages (like gcc to cross-armv7l-gcc-accel, etc) obstag has helped this to some extent and now that we utilize fakeobs & rsyncable source releases in Mer, anyone can set up a working setup with ease. > === NOTE === > The information contained in this E-mail message is > intended only for use of the individual or entity > named above. If the reader of this message is not > the intended recipient, or the employee or agent > responsible to deliver it to the intended recipient, > you are hereby notified that any dissemination, > distribution or copying of this communication is > strictly prohibited. > ============= Someone should outlaw these signatures or at least create logic that disables them from mailing lists.. BR Carsten Munk _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
