FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-14-2012, 09:17 PM
Ciaran McCreesh
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 23:01:05 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 08/14/2012 10:56 PM, Ciaran McCreesh wrote:
> >
> > We can't change inherit behaviour in EAPI 5 anyway since it's a
> > global scope function, so I was planning to ignore it and hope that
> > by the time EAPI 6 comes along, people will have learned not to
> > write huge eclasses that do more than one thing.
>
> great idea, let's wait 5 years then

Sorry, but the Council voted down the "you can have it immediately"
approach because people got upset about file extensions.

--
Ciaran McCreesh
 
Old 08-14-2012, 09:51 PM
Michał Górny
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 14:09:17 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 08/14/2012 01:54 PM, Michał Górny wrote:
> > On Tue, 14 Aug 2012 21:45:56 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> >
> >> On Tue, 14 Aug 2012 11:44:49 +0200
> >> Michał Górny <mgorny@gentoo.org> wrote:
> >>> As some of you may have noticed, lately introduced 'double include
> >>> preventions' have caused changes in effective phase functions in a
> >>> few ebuilds. Also, often it is undesirable that change in inherits
> >>> of an eclass may cause an undesired change of exported functions.
> >>
> >> The problem here is that eclasses aren't clearly split between
> >> "utility" and "does stuff", so people are inheriting "does stuff"
> >> eclasses to get utilities. The fix is to stop having stupidly huge
> >> complicated eclasses; changing inherit behaviour is just
> >> wallpapering over the gaping hole.
>
> Ciaran's assessment sounds pretty accurate to me.
>
> > Soo, how do you propose to handle bug 422533 without changing
> > inherit behavior?
>
> Close it as WONTFIX. The ifndef thing that we're doing now seems like
> a reasonable approach.

But you're aware that this 'reasonable approach' just made the whole
problem by changing exported functions, right?

--
Best regards,
Michał Górny
 
Old 08-14-2012, 09:56 PM
Ciaran McCreesh
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 23:51:17 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> But you're aware that this 'reasonable approach' just made the whole
> problem by changing exported functions, right?

No, what made the whole problem is awful eclasses that do far too many
things.

--
Ciaran McCreesh
 
Old 08-14-2012, 09:59 PM
Zac Medico
 
Default Exporting phase funcs from direct inherits only

On 08/14/2012 02:51 PM, Michał Górny wrote:
> On Tue, 14 Aug 2012 14:09:17 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>
>> On 08/14/2012 01:54 PM, Michał Górny wrote:
>>> On Tue, 14 Aug 2012 21:45:56 +0100
>>> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>>>
>>>> On Tue, 14 Aug 2012 11:44:49 +0200
>>>> Michał Górny <mgorny@gentoo.org> wrote:
>>>>> As some of you may have noticed, lately introduced 'double include
>>>>> preventions' have caused changes in effective phase functions in a
>>>>> few ebuilds. Also, often it is undesirable that change in inherits
>>>>> of an eclass may cause an undesired change of exported functions.
>>>>
>>>> The problem here is that eclasses aren't clearly split between
>>>> "utility" and "does stuff", so people are inheriting "does stuff"
>>>> eclasses to get utilities. The fix is to stop having stupidly huge
>>>> complicated eclasses; changing inherit behaviour is just
>>>> wallpapering over the gaping hole.
>>
>> Ciaran's assessment sounds pretty accurate to me.
>>
>>> Soo, how do you propose to handle bug 422533 without changing
>>> inherit behavior?
>>
>> Close it as WONTFIX. The ifndef thing that we're doing now seems like
>> a reasonable approach.
>
> But you're aware that this 'reasonable approach' just made the whole
> problem by changing exported functions, right?

That just means that somebody made a mistake. They should have put the
EXPORT_FUNCTIONS call *outside* of the ifndef block. Just educate people
about the correct place to put the EXPORT_FUNCTIONS call, and that
problem is solved.
--
Thanks,
Zac
 
Old 08-18-2012, 03:19 AM
Mike Frysinger
 
Default Exporting phase funcs from direct inherits only

On Tuesday 14 August 2012 17:59:40 Zac Medico wrote:
> That just means that somebody made a mistake. They should have put the
> EXPORT_FUNCTIONS call *outside* of the ifndef block. Just educate people
> about the correct place to put the EXPORT_FUNCTIONS call, and that
> problem is solved.

sounds fine
-mike
 
Old 08-18-2012, 03:20 AM
Mike Frysinger
 
Default Exporting phase funcs from direct inherits only

On Tuesday 14 August 2012 16:39:57 Michał Górny wrote:
> On Tue, 14 Aug 2012 12:46:30 -0700 Zac Medico wrote:
> > On 08/14/2012 02:44 AM, Michał Górny wrote:
> > > 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.

the "other way" is "the way EXPORT_FUNCS has always worked", so it's not like
it's anything new for people to wrassl' with
-mike
 

Thread Tools




All times are GMT. The time now is 01:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org