[oe] [meta-browser][PATCH v2] chromium: List all PACKAGECONFIG settings to avoid warning

Max Krummenacher max.oss.09 at gmail.com
Wed Jul 1 19:36:08 UTC 2015


Hi

Am Mittwoch, den 01.07.2015, 16:47 +0100 schrieb Burton, Ross:
> On 1 July 2015 at 15:12, Gary Thomas <gary at mlbassoc.com> 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





More information about the Openembedded-devel mailing list