Re: [gentoo-dev] Re: Re: RFC: New build types

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]