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
