EXPORT_FUNCTIONS - change in behaviour proposal

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

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

With an "EXPORT_FUNCTIONS = do_stuff" in alpha.bbclass, wouldn't that still work without the intermediaries though?

Cheers,

Richard

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

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