[oe] overriding tasks with EXPORT_FUNCTIONS

[Paul Eggleton]

On Monday 14 July 2014 09:33:25 Robert P. J. Day wrote:
> On Mon, 14 Jul 2014, Burton, Ross wrote:
> > On 14 July 2014 13:20, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
> > > but, as far as i can tell, that is the only class that requires a
> > > package name hook, and it simply defines its own implementation -- it
> > > does nothing with package.bbclass and makes no reference to the
> > > exported function package_package_name_hook(). so am i just
> > > misunderstanding something? what was the point of defining and
> > > exporting that function in package.bbclass if no other class takes
> > > advantage of it?
> > 
> > So there needs to be an empty implementation and EXPORT_FUNCTION for
> > package_package_name_hook so that you don't get "cannot find
> > function package_name_hook" when you don't have the debian.bbclass
> > enabled.
> > 
> > In cleaning that up I proposed removing the EXPORT_FUNCTION entirely
> > for the hook, but Richard recalled there being something out there
> > that did use the ability to chain up into debian.bbclass's
> > implementation, so I kept it.
> 
>   uh oh ... now i'm a bit confused again so let me back up a bit
> because i really want to understand this. my apologies for the tedium.
> 
>   as i read it, the only purpose of EXPORT_FUNCTIONS is to support the
> idea of being able to qualify a function with its class name so that
> you can (effectively) have access to more than one function with the
> same "name" at the same time. first, let's see where this is *not*
> necessary.
> 
>   as an example, base.bbclass defines the routine:
> 
> oe_runmake() {
>         oe_runmake_call "$@" || die "oe_runmake failed"
> }
> 
> now, since every class automatically inherits base.bbclass, all of
> those classes can call oe_runmake(), right? that routine is in their
> namespace, there is no need to export it, and they will all get that
> function as it's defined in base.bbclass.
> 
>   in addition, even if a class inherits base.bbclass, it has the right
> to totally override that routine by redefining a new oe_runmake(),
> yes? (or possibly _appending or _prepending to it.) in any event, at
> any time, there is only one definition of a function called
> oe_runmake() in scope. so far, so good?

Yes.

>   what EXPORT_FUNCTIONS appears to do is simply allow you access to
> more than one function with the same "name", so let's look at
> base.bbclass and, say, the do_fetch() routine:
> 
> python base_do_fetch() {
>     ... snip code ...
> }
> ...
> EXPORT_FUNCTIONS do_fetch
> 
> what does the above do? it now allows you to define, say,
> derived.bbclass, and define a new do_fetch() in terms of the base
> do_fetch(), as in:
> 
> do_fetch() {
>     ...
>     base_do_fetch()
>     ...
> }
> 
> however, if i created a new class that had no interest in redefining
> do_fetch() and i was happy with the base definition, i could simply
> continue to use the name do_fetch(), correct? the fact that that
> function was exported in base.bbclass is not relevant to me if i am
> not trying to redefine the name. (i suspect i could also refer to it
> by the name base_do_fetch() if i wanted, but that's unnecessary.)

Yes.

>   that's why i was confused by ross' earlier paragraph about
> package_name_hook being defined in package.bbclass -- unless some
> other class is going to try to access two functions called
> "package_naem_hook" at the same time, i currently see no need to
> export it in package.bbclass. however, if there was something else
> going on somewhere that needed this as richard purdie suggested, then
> i'd be interested in knowing what that is just to understand the whole
> picture.

I'm not sure what that example was I'm afraid, but maybe Richard can fill in 
the blanks.

Cheers,
Paul;

-- 

Paul Eggleton
Intel Open Source Technology Centre