1 |
Dirkjan Ochtman <djc@g.o> writes: |
2 |
|
3 |
> I guess by now pretty much everyone knows that the python eclass is |
4 |
> rather complex, and that this poses some problems. This has also been |
5 |
> an important cause for the disagreements between Arfrever and some of |
6 |
> the other developers. Since it appears that Arfrever won't be |
7 |
> committing much code to gentoo-x86 in the near future, I'm trying to |
8 |
> figure out where we should go with the python.eclass. This email is an |
9 |
> attempt at figuring that out, plus eliciting ideas to come up with a |
10 |
> general framework that will also solve this for ruby and other similar |
11 |
> runtimes (while supporting some of the features that the current |
12 |
> python eclass has, but that ruby-ng doesn't have). |
13 |
> |
14 |
> So I know a bunch of people have already looked at it, and I'd like to |
15 |
> know: what do you find better about the Ruby approach compared to the |
16 |
> Python approach? Is it just the size of python.eclass, or are there a |
17 |
> number of other issues? |
18 |
|
19 |
Let's skip the Ruby step, and go directly to Common Lisp! |
20 |
|
21 |
-- |
22 |
__Pascal Bourguignon__ http://www.informatimago.com/ |
23 |
A bad day in () is better than a good day in {}. |