[oe] overriding tasks with EXPORT_FUNCTIONS

[Robert P. J. Day]

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?

  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.)

  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.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================