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@g.o mailing list