1 |
On 08/14/2012 02:51 PM, Michał Górny wrote: |
2 |
> On Tue, 14 Aug 2012 14:09:17 -0700 |
3 |
> Zac Medico <zmedico@g.o> wrote: |
4 |
> |
5 |
>> On 08/14/2012 01:54 PM, Michał Górny wrote: |
6 |
>>> On Tue, 14 Aug 2012 21:45:56 +0100 |
7 |
>>> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
8 |
>>> |
9 |
>>>> On Tue, 14 Aug 2012 11:44:49 +0200 |
10 |
>>>> Michał Górny <mgorny@g.o> wrote: |
11 |
>>>>> As some of you may have noticed, lately introduced 'double include |
12 |
>>>>> preventions' have caused changes in effective phase functions in a |
13 |
>>>>> few ebuilds. Also, often it is undesirable that change in inherits |
14 |
>>>>> of an eclass may cause an undesired change of exported functions. |
15 |
>>>> |
16 |
>>>> The problem here is that eclasses aren't clearly split between |
17 |
>>>> "utility" and "does stuff", so people are inheriting "does stuff" |
18 |
>>>> eclasses to get utilities. The fix is to stop having stupidly huge |
19 |
>>>> complicated eclasses; changing inherit behaviour is just |
20 |
>>>> wallpapering over the gaping hole. |
21 |
>> |
22 |
>> Ciaran's assessment sounds pretty accurate to me. |
23 |
>> |
24 |
>>> Soo, how do you propose to handle bug 422533 without changing |
25 |
>>> inherit behavior? |
26 |
>> |
27 |
>> Close it as WONTFIX. The ifndef thing that we're doing now seems like |
28 |
>> a reasonable approach. |
29 |
> |
30 |
> But you're aware that this 'reasonable approach' just made the whole |
31 |
> problem by changing exported functions, right? |
32 |
|
33 |
That just means that somebody made a mistake. They should have put the |
34 |
EXPORT_FUNCTIONS call *outside* of the ifndef block. Just educate people |
35 |
about the correct place to put the EXPORT_FUNCTIONS call, and that |
36 |
problem is solved. |
37 |
-- |
38 |
Thanks, |
39 |
Zac |