[oe] USE flags - why they won't work for OE

Richard Purdie rpurdie at rpsys.net
Tue Sep 11 21:10:23 UTC 2007


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






More information about the Openembedded-devel mailing list