2011/10/21 Lauri T. Aarnio <[email protected]>: > > On Oct 19, 2011, at 2:44 PM, ext Carsten Munk wrote: > >> In practice, SB2 would have to install every single package build-dep >> on x86 side for perl etc that the ARM side packages would need and >> keep them updated. > > No, not all. It doesn't "have to" be like that. Content can be different on > ARM- and x86 sides, and still SB2 can be combine it all to a working build > environment. I'm not saying it can't, but it can also have adverse effects.
> > 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 2) We have SB2 doing mapping to a x86 perl and has selected tools/extensions compiled for x86 too which doesn't include perl-SSLeay 3) For this compile to be successful with an accelerated perl, this extension would be have to be added for x86 too and otherwise cause a fail in compilation due to missing extension I feel there's unforseen consequences if we don't keep sources and versions in sync on both X86 and ARM side, just try to remember how much of a mess SB1 devkits turned out to be in non-upgradability and being out of sync with what actually existed :) - and potential differences in how a native machine would build a package vs how a cross compiled one would be. I'm aware this approach with maintaining a tools distribution that doesn't have to be updated so often probably works in a most-developers-inside-one-company and strict requirements/dependency checking but this was a problem that people in community hit quite a lot when building software for Maemo as an example. That said - if you keep the source packages in sync (as OBS can do) and map a x86 version instead of ARM version of each interpreted-language-extension through SB2 mapping, it might work. I'd like to see a SB2 approach to OBS building of RPMs - it might have some benefits (such as non-root local builds) and perhaps can do it faster. Would be good to get statistics on the table for what speed benefit it has :). If you'd like to start with that, you can try to package up sb2 for RPM, and hack the 'build' package to be running SB2 instead of rpmbuild. You can do this on local builds too. But a definite no to a tools distribution that we map to that's not updated so often. It's a maintainability nightmare. Packages that are being built should be built using tools that are from the OS they're being built for or we're in for a world of hurt. BR Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
