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