From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@openembedded.org
Subject: USE flags - why they won't work for OE
Date: Tue, 11 Sep 2007 22:10:23 +0100 [thread overview]
Message-ID: <1189545023.6163.57.camel@localhost.localdomain> (raw)
In-Reply-To: <46E6EC08.209@student.utwente.nl>
On Tue, 2007-09-11 at 21:27 +0200, Koen Kooi wrote:
> Leon Woestenberg schreef:
> > Hello all,
> >
>
> > Maybe a minimal set of USE flags instead of creating -lite or -minimal
> > .bb is an option?
> > Or, using an include file that defines configuration variables
> > (HAVE_GTK, HAVE_X)?
>
> Any form of USE flags is *bad* and *unacceptable*. I'll leave it to the other core people
> to throw around terms like 'deterministic' and 'package space' :)
Agreed. I will try and keep this brief whilst putting something in the
archives once and for all.
If we implement USE flags people can no longer know what options
"matchbox-wm" (or whatever other package) was compiled with. Reproducing
builds then becomes a nightmare and differences would not be obvious. It
also has potential to break dependencies since something depending on
matchbox-wm might need certain configure options and it has no way to
specify this in the package dependencies.
We'd also get people complaining that they enabled gtk, built a
gpe-image in an existing build directory and why did it screw up badly
with half the components compiled without gtk? USE flags would be
something totally outside the existing dependency and timestamp/rebuild
tracking which is already complex enough.
Given this, the agreed approach in the past has been to create things
like "bluez-utils-nodbus". Its obvious whats missing from that package
and it works in feeds and dependencies.
Marcin's proposal of "bluez-utils-lite" is therefore in keeping with
this idea and he's demonstrated a clear cut need for it (massively
reduced build time for small images).
I'd also point out that OE has managed extremely well up to this point
without USE flags. I agree there are some corner cases where they're
help in theory but we can solve these problems in other ways.
Suggestions for better ways to handle this are extremely welcome but
"USE flags" as I understand the idea would turn into a nightmare and any
proposal needs to work for OE, not shoehorn in something from elsewhere
which doesn't fit.
Cheers,
Richard
next prev parent reply other threads:[~2007-09-11 21:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 11:18 Task-base is big :( Marcin Juszkiewicz
2007-09-11 17:37 ` Leon Woestenberg
2007-09-11 19:27 ` Koen Kooi
2007-09-11 21:10 ` Richard Purdie [this message]
2007-09-11 23:14 ` USE flags - why they won't work for OE Leon Woestenberg
2007-09-12 5:55 ` Stelios Koroneos
2007-09-12 11:06 ` José Bernardo Bandos Rodrigues
2007-09-12 16:38 ` Darcy Watkins
2007-09-12 11:46 ` Leon Woestenberg
2007-09-12 21:35 ` Richard Purdie
2007-09-11 21:17 ` Task-base is big :( Richard Purdie
2007-09-11 22:22 ` Detlef Vollmann
2007-09-11 22:55 ` Leon Woestenberg
2007-09-12 5:56 ` Stelios Koroneos
2007-09-12 7:53 ` Graeme Gregory
2007-09-12 8:43 ` Koen Kooi
2007-09-12 12:02 ` Binary packages (was: Task-base is big :( ) Detlef Vollmann
2007-09-12 12:45 ` Task-base is big :( Detlef Vollmann
2007-09-12 23:21 ` Richard Purdie
2007-09-11 23:43 ` Dr. Michael Lauer
2007-09-12 6:04 ` Koen Kooi
2007-09-14 7:21 ` Splitting up bluez in a sane way, was " Koen Kooi
2007-09-14 9:22 ` Marcin Juszkiewicz
2007-09-14 9:44 ` Koen Kooi
2007-09-15 8:29 ` Koen Kooi
2007-09-15 12:31 ` Marcin Juszkiewicz
2007-09-15 12:59 ` Koen Kooi
2007-09-18 17:54 ` Koen Kooi
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=1189545023.6163.57.camel@localhost.localdomain \
--to=rpurdie@rpsys.net \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@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.