Re: [PATCH 1/2] qt4(-embedded).inc: create variables to ease overriding

[Andreas Oberritter <obi@opendreambox.org>]

On 22.05.2012 15:36, Paul Eggleton wrote:
> On Tuesday 22 May 2012 15:28:17 you wrote:
>> On 22.05.2012 14:51, Paul Eggleton wrote:
>>> I think when we start getting to this level, especially because some of
>>> these options imply extra DEPENDS, we should try to use PACKAGECONFIG
>>> rather than specific variables.
>>
>> Introducing PACKAGECONFIG is a more complex change. It can still be done
>> in a later patch. 
> 
> It could be, but then we're introducing variables that will potentially go 
> into people's distro configs only to take them away in the near future. I'm not 
> especially keen on doing that.
> 
>> This patch just follows the semantics introduced by
>> QT_SQL_DRIVER_FLAGS 
> 
> Right, and when that was introduced some time ago we did not have 
> PACKAGECONFIG at all.
> 
> I realise this puts extra burden upon you, sorry about that. I can perhaps 
> offer to do the PACKAGECONFIG changes for you, but I won't be able to get to 
> them until next week at the earliest.

No need to hurry. I'll keep using my patch in my denzil-based branch
anyway, because denzil-next is unlikely to include either variant.

I'm not a big fan of PACKAGECONFIG. Its syntax is hard to read and hard
to write, maybe unless you're the inventor of it.

Looking for users of PACKAGECONFIG in OE-Core denzil, I saw it's used in
only 6 recipes. Even less in meta-openembedded (exactly 1). It looks
like it's not going to get adopted by many. So your statement about
taking away newly created variables in the near future is not
necessarily going to become true.

Besides that, introducing a new PACKAGECONFIG variable for Qt, that
includes new flags for basically everything already in QT_CONFIG_FLAGS,
doesn't seem to be an improvement.

Furthermore, as I understand it, PACKAGECONFIG handles only simple
on/off switches, but QT_CONFIG_FLAGS has switches for
on/off/plugin/system etc., and not everything you can build into qt can
be built as a plugin and vice versa, so the resulting set of
PACKAGECONFIG flags will likely become quite huge in order to be able to
express all options.

Regards,
Andreas