Hi Am Mittwoch, den 01.07.2015, 16:47 +0100 schrieb Burton, Ross: > On 1 July 2015 at 15:12, Gary Thomas <[email protected]> wrote: > > > No, it's much better to use the standard mechanism (PACKAGECONFIG) rather > > than making up something special for this recipe. The patch is needed only > > to suppress warnings about how it's being used. > > > > I kinda of agree with Robert here - the standard method isn't being used, > but the variable is being used. > > As the chromium recipe doesn't inherit autotools EXTRA_OECONF will only be > set by the PACKAGECONFIG handler, so it would be an improvement if the > enable/disable arguments were specified as usual in the flags and then > EXTRA_OEGYP just included EXTRA_OECONF. (untested but might work, cmake > recipes certainly did this) > > Ross
I think that this view is guided by an inside view on PACKAGECONFIG. For the guys wanting to influencing the build of a package they want to set a list of options and then forget about it. So having to write in your bbappend something like PACKAGECONFIG += "use-egl" PACKAGECONFIG_NON_CONFIGOPTION += "component-build" instead of PACKAGECONFIG += "use-egl component-build" is sort of unintutive. I guess the warning which now pops up when not setting a value in PACKAGECONFIG which does not have a corresponding PACKAGECONFIG[value] is meant to warn of a typo in setting PACKAGECONFIG. Gary's solution would even provide the same warning mechanism for free while when moving to a PACKAGECONFIG_NON_CONFIGOPTION one would have to implement another test to get a warning when providing a non supported value to PACKAGECONFIG_NON_CONFIGOPTION. Just my two cents. Regards Max -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
