From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Andreas Oberritter <obi@opendreambox.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2] qt4(-embedded).inc: create variables to ease overriding
Date: Tue, 22 May 2012 15:49:43 +0100 [thread overview]
Message-ID: <7503511.eEOeCZTR2f@helios> (raw)
In-Reply-To: <4FBB9E6C.6030509@opendreambox.org>
On Tuesday 22 May 2012 16:10:52 Andreas Oberritter wrote:
> 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.
Can you suggest an alternative syntax that we could have consistent across
multiple recipes and handles adding/removing DEPENDS as well as configure
options? That is what it attempts to provide.
> 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.
It's still pretty new. Besides, we haven't exactly gone out on a program of
adding it everywhere there is a configuration option for something - we only
add it on an as-needed basis.
> 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.
It is now our standard way of switching on and off features particularly where
those features imply a change to DEPENDS.
> 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.
So this might present a problem I agree. Perhaps PACKAGECONFIG is not going to
work here. I dislike however that we would have the ability to configure these
options and yet there is no management of DEPENDS to match.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
prev parent reply other threads:[~2012-05-22 14:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 11:37 [PATCH 1/2] qt4(-embedded).inc: create variables to ease overriding Andreas Oberritter
2012-05-22 11:37 ` [PATCH 2/2] qt4.inc: package keyboard drivers Andreas Oberritter
2012-05-22 12:51 ` [PATCH 1/2] qt4(-embedded).inc: create variables to ease overriding Paul Eggleton
2012-05-22 13:28 ` Andreas Oberritter
2012-05-22 13:36 ` Paul Eggleton
2012-05-22 14:10 ` Andreas Oberritter
2012-05-22 14:49 ` Paul Eggleton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7503511.eEOeCZTR2f@helios \
--to=paul.eggleton@linux.intel.com \
--cc=obi@opendreambox.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.