[OE-core] [bitbake-devel] EXPORT_FUNCTIONS - change in behaviour proposal
Richard Purdie
richard.purdie at linuxfoundation.org
Tue Dec 11 00:12:10 UTC 2012
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 at 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
More information about the Openembedded-core
mailing list