1 |
On Tue, 14 Aug 2012 12:46:30 -0700 |
2 |
Zac Medico <zmedico@g.o> wrote: |
3 |
|
4 |
> On 08/14/2012 02:44 AM, Michał Górny wrote: |
5 |
> > Hello, |
6 |
> > |
7 |
> > As some of you may have noticed, lately introduced 'double include |
8 |
> > preventions' have caused changes in effective phase functions in a |
9 |
> > few ebuilds. |
10 |
> |
11 |
> Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of |
12 |
> the ifndef block? The function implementations themselves can be |
13 |
> inside the ifndef block, since that only need to be sourced once. |
14 |
|
15 |
Isn't that an awful kind of undefined behavior? We're already |
16 |
on a slippery ground assuming that sourced data changes between |
17 |
inherits. Assuming EXPORT_FUNCS will work some other ugly way is even |
18 |
worse. |
19 |
|
20 |
> > Also, often it is undesirable that change in inherits of |
21 |
> > an eclass may cause an undesired change of exported functions. To |
22 |
> > solve these problems, we are proposing the following: |
23 |
> > |
24 |
> > |
25 |
> > 1. If an ebuild does not provide an explicit phase function, the |
26 |
> > phase functions *directly exported* by *directly inherited* |
27 |
> > eclasses are used to find a suitable default, |
28 |
> > |
29 |
> > 2. Thus, if an eclass inherits another eclass and expects the phase |
30 |
> > functions of that eclass to be effective to the ebuild, it needs to |
31 |
> > create its own phase function and export it. |
32 |
> > |
33 |
> > |
34 |
> > This should make the ebuild behavior simpler to understand and |
35 |
> > saner. It should also fix the forementioned issues, and allow us to |
36 |
> > make the 'source eclasses only once'[1] proposal simpler. |
37 |
> > |
38 |
> > [1]:https://bugs.gentoo.org/show_bug.cgi?id=422533 |
39 |
> |
40 |
> I'm not sure that your cure isn't worse than the disease. |
41 |
|
42 |
In any case, 2. should happen even now. Eclasses should be simple |
43 |
and predictable, and debugging random failures isn't something nice. |
44 |
Unless you're saying that adding phase functions overrides to |
45 |
work-around failures which you don't even understand is a good solution. |
46 |
|
47 |
-- |
48 |
Best regards, |
49 |
Michał Górny |