1 |
Rémi Cardona wrote: |
2 |
|
3 |
> Steve Long a écrit : |
4 |
>> First and foremost to give an environment wherein people can write their |
5 |
>> installation scripts using the language they are most comfortable with. |
6 |
> |
7 |
> If bash is not "easy" or straightforward enough for what you are trying |
8 |
> to achieve, then I'd say the package is broken (ie, hand-made configure |
9 |
> script, odd makefiles and whatnot). Better fix the package rather than |
10 |
> rewriting ebuilds, make the world a better place. |
11 |
> |
12 |
Heh, I'm fine with BASH believe it or not ;p nor do I have that much |
13 |
interest in the other scripting languages. I really just think it would |
14 |
make porting stuff to Gentoo a lot simpler for people who don't know Cbut |
15 |
do know their language of choice. |
16 |
|
17 |
>> Secondly efficiency; in the case of a pbuild it could be run from within |
18 |
>> the PM; for something like a jbuild it would use the native tools and |
19 |
>> existing libraries like ANT. For hbuild it would tie into Cabal. While |
20 |
>> these may be used already, we go from PM -> BASH -> LangX. I'm just |
21 |
>> saying give the _option_ to leave out the BASH bit when you have mature |
22 |
>> tools in langX. |
23 |
> |
24 |
> Care to back that up with any sort of figure or number? Is bash really |
25 |
> the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the |
26 |
> bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash. |
27 |
> |
28 |
> But then again, I don't have any numbers to back that up either... |
29 |
> |
30 |
I don't have figures, but my understanding is that one of the major factors |
31 |
in pkgcore's speed (which *is* impressive, even if the UI isn't quite there |
32 |
yet) is that it doesn't reload bash for every phase. (The whole |
33 |
ebuild "daemon" or ebd thing.) |
34 |
|
35 |
> Honestly, maybe it could be a fun project, but I'm hardly convinced it |
36 |
> would bring any sort of real advantage to the tree. In fact, having |
37 |
> ebuilds in many languages would probably wreak havoc more than anything |
38 |
> else. |
39 |
> |
40 |
I don't see how it would wreak more havoc than a novice using, eg ANT from |
41 |
Java which s/he is comfortable with, and then further having to learn BASH |
42 |
peculiarities when things don't fit with the eclass. But yeah, the fun is |
43 |
what attracts me to the idea more than anything. |
44 |
|
45 |
It's something I'd imagine would be used only for packages developed in the |
46 |
relevant overlay, since that's where the people who know the language |
47 |
develop stuff (and they'd be the ones maintaining their version.) However, |
48 |
they'd need to know that, once they've signed off on it, the central tree |
49 |
will support it without further code changes. |
50 |
|
51 |
|
52 |
-- |
53 |
gentoo-dev@l.g.o mailing list |