packageconfig, add depends if feature is disabled

Hi

The recent unconditional move towards gtk3 in oe-core forces me to follow with some of my recipes.

I tried this with packageconfig, however there seems to be no easy way to specify DEPENDS in case a packageconfig feature is disabled. i.e. for gtk3 we need gtk+3 in depends while for gtk2 we need gtk+. I ended up with:

    PACKAGECONFIG ?= "gtk3"
    PACKAGECONFIG[gtk3] = "--enable-gtk3,,gtk+3"
    python __anonymous () {
        depends = d.getVar("DEPENDS", d, 1)
        if 'gtk3' not in d.getVar('PACKAGECONFIG', True):
            d.setVar("DEPENDS", "%s gtk+" % depends)
    }

The following would also be possible but then nothing makes sure that one, and exactly one of gtk2, gtk3 is in PACKAGECONFIG.

    PACKAGECONFIG ?= "gtk3"
    PACKAGECONFIG[gtk2] = ",,gtk+"
    PACKAGECONFIG[gtk3] = "--enable-gtk3,,gtk+3"

Any ideas?
Would this use case merit an extension to packageconfig, e.g.:

# PACKAGECONFIG ??= "<default options>"
# PACKAGECONFIG[foo] = "--enable-foo,--disable-foo,
foo_depends,foo_runtime_depends, not_foo_depends,not_foo_rdepends"

Which would simplify the above to:

PACKAGECONFIG ?= "gtk3" PACKAGECONFIG[gtk3] = "--enable-gtk3,,gtk+3,,gtk+"

Regards
Max

PACKAGECONFIGs are meant to be explicit so "thing which is enabled when something else is disabled" is obvious unless you write log comments explaining the options.

For example, what if PACKAGECONFIG was set to "" but gtk+ was already in the sysroot. By the logic you've described that would result in your recipe being built with gtk+ despite being told not to, or maybe if gtk3 is autodetected first and that's also in the sysroot then gtk3 gets used instead. You literally can't tell, and if bitbake can't tell then you'll have binary packages changing when they shouldn't be.

Idiomatically you'd have - or expect - something like

    PACKAGECONFIG ?= "gtk3"
    PACKAGECONFIG[gtk2] = "--enable-gtk2,--disable-gtk2,gtk+"
    PACKAGECONFIG[gtk3] = "--enable-gtk3,--disable-gtk3,gtk+3"

If the upstream doesn't support this then you're hoping that they don't change the default values, or the configure doesn't attempt to auto-detect, or various other ways that having options with no enable or disable values can break. At that point I'd actually fix upstream's configure and send a patch instead of attempting to work around it.

Ross

Hi Ross

Am Sonntag, den 19.06.2016, 20:51 +0100 schrieb Burton, Ross:

Understood. Will have a look into configure of the packages.

Thanks
Max