On Thu, Mar 20, 2008 at 06:51:13AM +0000, Steve Long wrote: > Rémi Cardona wrote: > > > Steve Long a écrit : > >> First and foremost to give an environment wherein people can write their > >> installation scripts using the language they are most comfortable with. > > > > If bash is not "easy" or straightforward enough for what you are trying > > to achieve, then I'd say the package is broken (ie, hand-made configure > > script, odd makefiles and whatnot). Better fix the package rather than > > rewriting ebuilds, make the world a better place. > > > Heh, I'm fine with BASH believe it or not ;p nor do I have that much > interest in the other scripting languages. I really just think it would > make porting stuff to Gentoo a lot simpler for people who don't know Cbut > do know their language of choice. > > >> Secondly efficiency; in the case of a pbuild it could be run from within > >> the PM; for something like a jbuild it would use the native tools and > >> existing libraries like ANT. For hbuild it would tie into Cabal. While > >> these may be used already, we go from PM -> BASH -> LangX. I'm just > >> saying give the _option_ to leave out the BASH bit when you have mature > >> tools in langX. > > > > Care to back that up with any sort of figure or number? Is bash really > > the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the > > bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash. > > > > But then again, I don't have any numbers to back that up either... > > > I don't have figures, but my understanding is that one of the major factors > in pkgcore's speed (which *is* impressive, even if the UI isn't quite there > yet) is that it doesn't reload bash for every phase. (The whole > ebuild "daemon" or ebd thing.)
From a speed standpoint, EBD is only relevant if we're talking about metadata regeneration- http://gentooexperimental.org/~ferringb/blog/archives/2005-03.html#e2005-03-05T16_59_39.txt Generally speaking, if you're sourcing to get metadata (regardless of the underlying format), you're already screwed- cache exists for a reason and is massively faster to rely on. Pkgcore's speed comes about from careful design + a massive amount of JIT, EBD is faster then the alternatives but that's *only* relevant for metadata regeneration. Finally, bear in mind we're talking about build phase here- even if the pkg is just a straight unpack/copy, the bottleneck there isn't going to be the bash bits for setting up the env, it's going to be the unpack, copy, multiple QA checks that do repeated find's across ${D}, multiple file invocations for same file, etc. Seriously- profile a merge sometime, even on non-compilations the large time slices are never bash. ~brian
pgpXWz5ckvRsg.pgp
Description: PGP signature
