On 19 June 2016 at 10:52, Max Krummenacher <[email protected]> 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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
