Hi Ross Am Sonntag, den 19.06.2016, 20:51 +0100 schrieb Burton, Ross: > 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
Understood. Will have a look into configure of the packages. Thanks Max -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
