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