EXPORT_FUNCTIONS - change in behaviour proposal

EXPORT_FUNCTIONS - change in behaviour proposal

[Richard Purdie]

After Enrico's reported problem, I've been poking around the
EXPORT_FUNCTIONS code. Currently OE-Core metadata generates list A
below. In particular, this leads to code like:

 do_configure calls gnomebase_do_configure
 gnomebase_do_configure calls autotools_do_configure

which has a level of indirection. The gnomebase class never references
do_configure. I can appreciate adding in a default mapping of:

 do_configure calls autotools_do_configure

since it allows a user to call into autotools_do_configure from a custom
do_configure but I can't see the value of the intermediary
gnomebase_do_configure. Does anyone know of a use for it?

I have a suspicion that if it ever did do anything useful, it stopped
being useful long ago.

I'm therefore strongly tempted to remove the intermediaries from the
code. This would result in list B below which is a more direct set of
mappings.

Any thoughts/comments from anyone?

Cheers,

Richard

List A:
 autotools_do_siteconfig calls siteconfig_do_siteconfig
 autotools_do_siteconfig_gencache calls siteconfig_do_siteconfig_gencache
 base_do_patch calls patch_do_patch
 cmake_do_configure calls autotools_do_configure
 cmake_do_install calls autotools_do_install
 core-image_do_rootfs calls image_do_rootfs
 core-image_make_zimage_symlink_relative calls image_make_zimage_symlink_relative
 core-image_remove_init_link calls image_remove_init_link
 core-image_rootfs_no_x_startup calls image_rootfs_no_x_startup
 core-image_rootfs_update_timestamp calls image_rootfs_update_timestamp
 core-image_set_image_autologin calls image_set_image_autologin
 core-image_zap_root_password calls image_zap_root_password
 do_compile calls base_do_compile
 do_compile calls cmake_do_compile
 do_compile calls cpan_do_compile
 do_compile calls distutils_do_compile
 do_compile calls kernel_do_compile
 do_compile calls module_do_compile
 do_compile calls setuptools_do_compile
 do_configure calls autotools_do_configure
 do_configure calls base_do_configure
 do_configure calls cmake_do_configure
 do_configure calls cml1_do_configure
 do_configure calls cpan_do_configure
 do_configure calls gnomebase_do_configure
 do_configure calls kernel_do_configure
 do_configure calls qmake2_do_configure
 do_configure calls qmake_base_do_configure
 do_deploy calls kernel_do_deploy
 do_fetch calls base_do_fetch
 do_generate_toolchain_file calls cmake_do_generate_toolchain_file
 do_install calls autotools_do_install
 do_install calls base_do_install
 do_install calls cmake_do_install
 do_install calls cpan_do_install
 do_install calls distutils_do_install
 do_install calls gnomebase_do_install
 do_install calls kernel_do_install
 do_install calls module_do_install
 do_install calls setuptools_do_install
 do_package calls base_do_package
 do_patch calls base_do_patch
 do_siteconfig calls autotools_do_siteconfig
 do_siteconfig_gencache calls autotools_do_siteconfig_gencache
 do_unpack calls base_do_unpack
 gnomebase_do_configure calls autotools_do_configure
 gnomebase_do_install calls autotools_do_install
 package_name_hook calls debian_package_name_hook
 qmake2_do_configure calls qmake_base_do_configure
 setuptools_do_compile calls distutils_do_compile
 setuptools_do_install calls distutils_do_install


List B:
 do_compile calls base_do_compile
 do_compile calls cmake_do_compile
 do_compile calls cpan_do_compile
 do_compile calls distutils_do_compile
 do_compile calls kernel_do_compile
 do_compile calls module_do_compile
 do_configure calls autotools_do_configure
 do_configure calls base_do_configure
 do_configure calls cmake_do_configure
 do_configure calls cml1_do_configure
 do_configure calls cpan_do_configure
 do_configure calls kernel_do_configure
 do_configure calls qmake_base_do_configure
 do_deploy calls kernel_do_deploy
 do_fetch calls base_do_fetch
 do_generate_toolchain_file calls cmake_do_generate_toolchain_file
 do_install calls autotools_do_install
 do_install calls base_do_install
 do_install calls cmake_do_install
 do_install calls cpan_do_install
 do_install calls distutils_do_install
 do_install calls kernel_do_install
 do_install calls module_do_install
 do_package calls base_do_package
 do_patch calls patch_do_patch
 do_siteconfig calls siteconfig_do_siteconfig
 do_siteconfig_gencache calls siteconfig_do_siteconfig_gencache
 do_unpack calls base_do_unpack
 package_name_hook calls debian_package_name_hook

Re: EXPORT_FUNCTIONS - change in behaviour proposal

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On Mon, Dec 10, 2012 at 9:09 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> After Enrico's reported problem, I've been poking around the
> EXPORT_FUNCTIONS code. Currently OE-Core metadata generates list A
> below. In particular, this leads to code like:
>
>  do_configure calls gnomebase_do_configure
>  gnomebase_do_configure calls autotools_do_configure
>
> which has a level of indirection. The gnomebase class never references
> do_configure. I can appreciate adding in a default mapping of:
>
>  do_configure calls autotools_do_configure
>
> since it allows a user to call into autotools_do_configure from a custom
> do_configure but I can't see the value of the intermediary
> gnomebase_do_configure. Does anyone know of a use for it?
>
> I have a suspicion that if it ever did do anything useful, it stopped
> being useful long ago.
>
> I'm therefore strongly tempted to remove the intermediaries from the
> code. This would result in list B below which is a more direct set of
> mappings.
>
> Any thoughts/comments from anyone?
>

In theory, I could see a situation where one class inherits another, rather
than just individual components all inherited by the recipe.

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.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

Re: [bitbake-devel] EXPORT_FUNCTIONS - change in behaviour proposal

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On Mon, Dec 10, 2012 at 9:09 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> After Enrico's reported problem, I've been poking around the
> EXPORT_FUNCTIONS code. Currently OE-Core metadata generates list A
> below. In particular, this leads to code like:
>
>  do_configure calls gnomebase_do_configure
>  gnomebase_do_configure calls autotools_do_configure
>
> which has a level of indirection. The gnomebase class never references
> do_configure. I can appreciate adding in a default mapping of:
>
>  do_configure calls autotools_do_configure
>
> since it allows a user to call into autotools_do_configure from a custom
> do_configure but I can't see the value of the intermediary
> gnomebase_do_configure. Does anyone know of a use for it?
>
> I have a suspicion that if it ever did do anything useful, it stopped
> being useful long ago.
>
> I'm therefore strongly tempted to remove the intermediaries from the
> code. This would result in list B below which is a more direct set of
> mappings.
>
> Any thoughts/comments from anyone?
>

In theory, I could see a situation where one class inherits another, rather
than just individual components all inherited by the recipe.

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.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

Re: EXPORT_FUNCTIONS - change in behaviour proposal

[Richard Purdie]

On Mon, 2012-12-10 at 10:29 -0700, Chris Larson wrote:
> On Mon, Dec 10, 2012 at 9:09 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>         After Enrico's reported problem, I've been poking around the
>         EXPORT_FUNCTIONS code. Currently OE-Core metadata generates
>         list A
>         below. In particular, this leads to code like:
>         
>          do_configure calls gnomebase_do_configure
>          gnomebase_do_configure calls autotools_do_configure
>         
>         which has a level of indirection. The gnomebase class never
>         references
>         do_configure. I can appreciate adding in a default mapping of:
>         
>          do_configure calls autotools_do_configure
>         
>         since it allows a user to call into autotools_do_configure
>         from a custom
>         do_configure but I can't see the value of the intermediary
>         gnomebase_do_configure. Does anyone know of a use for it?
>         
>         I have a suspicion that if it ever did do anything useful, it
>         stopped
>         being useful long ago.
>         
>         I'm therefore strongly tempted to remove the intermediaries
>         from the
>         code. This would result in list B below which is a more direct
>         set of
>         mappings.
>         
>         Any thoughts/comments from anyone?
>
> In theory, I could see a situation where one class inherits another,
> rather than just individual components all inherited by the recipe.
>
> 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?

Cheers,

Richard

Re: [bitbake-devel] EXPORT_FUNCTIONS - change in behaviour proposal

[Richard Purdie]

On Mon, 2012-12-10 at 10:29 -0700, Chris Larson wrote:
> On Mon, Dec 10, 2012 at 9:09 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>         After Enrico's reported problem, I've been poking around the
>         EXPORT_FUNCTIONS code. Currently OE-Core metadata generates
>         list A
>         below. In particular, this leads to code like:
>         
>          do_configure calls gnomebase_do_configure
>          gnomebase_do_configure calls autotools_do_configure
>         
>         which has a level of indirection. The gnomebase class never
>         references
>         do_configure. I can appreciate adding in a default mapping of:
>         
>          do_configure calls autotools_do_configure
>         
>         since it allows a user to call into autotools_do_configure
>         from a custom
>         do_configure but I can't see the value of the intermediary
>         gnomebase_do_configure. Does anyone know of a use for it?
>         
>         I have a suspicion that if it ever did do anything useful, it
>         stopped
>         being useful long ago.
>         
>         I'm therefore strongly tempted to remove the intermediaries
>         from the
>         code. This would result in list B below which is a more direct
>         set of
>         mappings.
>         
>         Any thoughts/comments from anyone?
>
> In theory, I could see a situation where one class inherits another,
> rather than just individual components all inherited by the recipe.
>
> 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?

Cheers,

Richard

Re: EXPORT_FUNCTIONS - change in behaviour proposal

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

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.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2062 bytes --]

Re: [bitbake-devel] EXPORT_FUNCTIONS - change in behaviour proposal

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

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.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2062 bytes --]

Re: EXPORT_FUNCTIONS - change in behaviour proposal

[Richard Purdie]

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

Re: [bitbake-devel] EXPORT_FUNCTIONS - change in behaviour proposal

[Richard Purdie]

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