| 1 |
Steve Long a écrit : |
| 2 |
> First and foremost to give an environment wherein people can write their |
| 3 |
> installation scripts using the language they are most comfortable with. |
| 4 |
|
| 5 |
If bash is not "easy" or straightforward enough for what you are trying |
| 6 |
to achieve, then I'd say the package is broken (ie, hand-made configure |
| 7 |
script, odd makefiles and whatnot). Better fix the package rather than |
| 8 |
rewriting ebuilds, make the world a better place. |
| 9 |
|
| 10 |
> Secondly efficiency; in the case of a pbuild it could be run from within the |
| 11 |
> PM; for something like a jbuild it would use the native tools and existing |
| 12 |
> libraries like ANT. For hbuild it would tie into Cabal. While these may be |
| 13 |
> used already, we go from PM -> BASH -> LangX. I'm just saying give the |
| 14 |
> _option_ to leave out the BASH bit when you have mature tools in langX. |
| 15 |
|
| 16 |
Care to back that up with any sort of figure or number? Is bash really |
| 17 |
the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the |
| 18 |
bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash. |
| 19 |
|
| 20 |
But then again, I don't have any numbers to back that up either... |
| 21 |
|
| 22 |
Honestly, maybe it could be a fun project, but I'm hardly convinced it |
| 23 |
would bring any sort of real advantage to the tree. In fact, having |
| 24 |
ebuilds in many languages would probably wreak havoc more than anything |
| 25 |
else. |
| 26 |
|
| 27 |
My 2¢ |
| 28 |
|
| 29 |
Cheers, |
| 30 |
|
| 31 |
Rémi |
| 32 |
-- |
| 33 |
gentoo-dev@l.g.o mailing list |
Archives