On Mon, 2012-12-10 at 12:41 -0700, Chris Larson wrote: > On Mon, Dec 10, 2012 at 10:44 AM, Richard Purdie > <[email protected]> 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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
