2011/10/21 Lauri T. Aarnio <lauri.t.aar...@nokia.com>: > > On Oct 21, 2011, at 4:05 PM, ext Carsten Munk wrote: > > That is where your assumptions go wrong. > > It isn't done like that. Or should't be, x86 perl must not used for running > scripts from target packages - either from the source package or from > target's binary packages. It simply isn't safe, and there are packages where > it fails. Badly.
Ah! That part I didn't know indeed. So, let's say I have a random foo.pl in my target, i run perl, you don't attempt to accelerate it at all? (definition of accelerate: use a x86 binary in place of perl). That is, let's say we provide autom4te in SB2 tools set, it'll be run with the 'x86' perl. OK, that is a fairly clever approach. I wonder if we could do something similar with the approach we currently use for cross compilation. > SB2's tools collection is based on two ideas > > 1) the contents must be built from the same sources as what goes to the > target FS > 2) it doesn't have to be updated so often, because it doesn't contain as much > stuff as what goes to the target side. And updating it could be automated. I wonder if we somehow can make that automated in OBS through the fact we utilize same sources. That could be interesting. > The big question is that what should go to the tools collection (what can be > put there, what can't). Some tools are easy to handle, some require more work > (like perl & python). But this is not something that would create an endless > maintenance loop. I think it could be useful, for all of us, to do some analysis on where exactly the pain points of compilation is these days. I know for a fact I'd like to speed up autoconf and friends, that's second-biggest painpoint I see. With the exception of perl taking a rebuild and utilizing it's own built (ARM) perl.. That's just slow and perl rebuilds a little too often for my own liking. > I have been prototyping just that... it isn't integrated to OBS yet, but > rpmbuilding with SB2 is possible. And easy. > Well, if you want a nice 312 public source package distribution to try it out on and get feedback on issues, I'd be interested in helping you out to test it on Mer. As I said in one of the earliest posts, it's always useful to evaluate technologies and well, there's no holy cows - we're open to ideas and innovation. 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
