Re: [PATCH][RFC] base.bbclass: Introduce EXTRA_CONF_PACKAGECONFIG variable

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2016-03-02 at 13:38 +0100, Martin Jansa wrote:
> On Sat, Feb 27, 2016 at 11:09:47PM +0100, Martin Jansa wrote:
> > * add separate variable for configuration options generated from
> >   PACKAGECONFIG setting, this helps other bbclasses and recipes
> >   to take advantage of PACKAGECONFIG mechanism, without including
> >   other options from EXTRA_OECONF
> > * e.g. meta-qt5 recipes are abusing EXTRA_OECONF to get options
> >   from PACKAGECONFIG:
> >   EXTRA_QMAKEVARS_PRE +=
> >   but with
> >   conf/distro/include/no-static-libs.inc
> >   it means getting --disable-static as invalid option inside
> >   EXTRA_QMAKEVARS_PRE as reported by Alexandre Belloni who tried
> >   to use poky with meta-qt5.
> > * once we migrate all bbclasses and recipes to
> > EXTRA_CONF_PACKAGECONFIG
> >   we should also restrict EXTRA_OECONF append only to
> > autotools.bbclass
> >   like I did for cmake.bbclass
> 
> No comments? Should I resend without [RFC] tag?
> 
> This is needed to fix couple components when
> conf/distro/include/no-static-libs.inc is used.

I can see the need for it, I'm just not 100% sure I like the form of
the patch. No one particular thing is doing that, just a general
feeling of unease which I can't quite put into words :(.

We continue to have a need to differentiate between "proper" autotools
recipes and non-autotools recipes which would make this kind of issue
easier. I guess I'm trying to weigh up whether we should consider
something a bit more invasive to try and improve things and if we do
that whether this patch helps or hinders that (it probably does help).

I'm also not 100% convinced EXTRA_CONF_PACKAGECONFIG is the right name,
but I can see how you got here and I'm not sure I have a better
suggestion (PACKAGECONFIG_CONFPARAMS? _CONFARGS?)

Cheers,

Richard