[gentoo-dev] Re: Re: RFC: New build types
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.) Honestly, maybe it could be a fun project, but I'm hardly convinced it would bring any sort of real advantage to the tree. In fact, having ebuilds in many languages would probably wreak havoc more than anything else. I don't see how it would wreak more havoc than a novice using, eg ANT from Java which s/he is comfortable with, and then further having to learn BASH peculiarities when things don't fit with the eclass. But yeah, the fun is what attracts me to the idea more than anything. It's something I'd imagine would be used only for packages developed in the relevant overlay, since that's where the people who know the language develop stuff (and they'd be the ones maintaining their version.) However, they'd need to know that, once they've signed off on it, the central tree will support it without further code changes. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: RFC: New build types
On Thu, Mar 20, 2008 at 06:51:13AM +, 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
Re: [gentoo-dev] Re: Re: RFC: New build types
Steve Long kirjoitti: I don't see how it would wreak more havoc than a novice using, eg ANT from Java which s/he is comfortable with, and then further having to learn BASH peculiarities when things don't fit with the eclass. But yeah, the fun is what attracts me to the idea more than anything. Java needs to be compiled and ant is meant to be started from the command line. Of course you can invoke the main method from Java but what's the point? Developers have to be able to review ebuilds and having all those different languages would make the job harder and I don't really see benefits. If you need something bit more complex done in an ebuild, you can always use something like inline python. Regards, Petteri signature.asc Description: OpenPGP digital signature
