1 |
On Fri, 4 May 2012 22:23:31 +0200 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> > There's all kinds of reasons to not use autotools-utils.eclass. |
5 |
> > I wouldn't want to see another python.eclass bullying around the tree. |
6 |
> |
7 |
> 504 autotools-utils.eclass |
8 |
> 3186 python.eclass |
9 |
> |
10 |
> Do you have any real arguments? |
11 |
|
12 |
I think his point was that like the python eclass, autotools-utils requires |
13 |
you to give up a lot of control over your ebuild to it. It started out as a |
14 |
simple way to standardize common autotools-related tasks. Then it began |
15 |
growing and adding a bunch of stuff that, while I'm sure was useful to some, |
16 |
I didn't need or had to handle differently. Then these features started |
17 |
becoming interdependent and I started getting bug reports about how my |
18 |
packages were misusing the eclass because I didn't want to cede full control |
19 |
over to its phase functions. |
20 |
|
21 |
Don't get me wrong, I understand the reasons why it has to work the way it |
22 |
does and I'm sure most people are fine with it. But I'm wary about giving |
23 |
that much power over to an eclass I can't control. I hate exported phase |
24 |
functions in general though, so read into that what you will. |
25 |
|
26 |
|
27 |
-- |
28 |
fonts, gcc-porting |
29 |
toolchain, wxwidgets |
30 |
@ gentoo.org |