Re: EXPORT_FUNCTIONS - change in behaviour proposal

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2012-12-10 at 12:41 -0700, Chris Larson wrote:
> On Mon, Dec 10, 2012 at 10:44 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>         > E.g. in class alpha:
>         >
>         > inherit beta
>         >
>         > alpha_do_stuff () {
>         >    pre_stuff
>         >    beta_do_stuff
>         >    post_stuff
>         > }
>         >
>         > But this is a theoretical case, and often we hack around
>         things via
>         > _prepend/_append rather than doing things like this, so I
>         doubt this
>         > is actually done anywhere in practice.
>         
>         
>         With an "EXPORT_FUNCTIONS = do_stuff" in alpha.bbclass,
>         wouldn't that
>         still work without the intermediaries though?
> 
> Hmm, yes, good point. Perhaps it was to allow the user to override an
> intermediate function that might or might not exist?
>
> E.g. in the do_configure calls gnomebase_do_configure calls
> autotools_do_configure case, the user could override
> gnomebase_do_configure, without having to know whether or not
> gnomebase actually defines a configure function?
>
> I'm guessing here, but that *could* be why it was implemented this
> way. In practice, however, we have to know what our classes are doing
> anyway, most of the time, for a wide variety of reasons. E.g. uses of
> overrides have to be operated against carefully to avoid your changes
> being blown away.

Could well be this was the reason. I think the exact class the current
code will pick for any intermediary is determined by parse order and I
can't find any case we actually use this property. As you say, I can't
see it being that useful in practise.

I've proposed a bitbake patch which removes the intermediary and
simplifies things a bit.

Cheers,

Richard