packageconfig, add depends if feature is disabled

packageconfig, add depends if feature is disabled

[Max Krummenacher]

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

Re: packageconfig, add depends if feature is disabled

[Burton, Ross]

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

On 19 June 2016 at 10:52, Max Krummenacher <max.oss.09@gmail.com> wrote:

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

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

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

Re: packageconfig, add depends if feature is disabled

[Max Krummenacher]

Hi Ross

Am Sonntag, den 19.06.2016, 20:51 +0100 schrieb Burton, Ross:
> On 19 June 2016 at 10:52, Max Krummenacher <max.oss.09@gmail.com>
> wrote:
> 
> >     PACKAGECONFIG ?= "gtk3"
> >     PACKAGECONFIG[gtk2] = ",,gtk+"
> >     PACKAGECONFIG[gtk3] = "--enable-gtk3,,gtk+3"
> > 
> 
> 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

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

Thanks
Max