[gobolinux-devel] Generic useflags

[Michael Homer]

On Sunday 06 July 2008 12:59:55 Isaac Dupree wrote:
> Michael Homer wrote:
> > Now, here comes your part in all this: tear the preceding to pieces and
> > show us why it's wrong.
>
> I'll try, even though it looks pretty enticing to me :-)
>
> > Where one of the flags encompassed by the generic flag was enabled
> > explicitly, the generic flag would do nothing. If a program had qt, gtk,
> > and tk interfaces, +gui +gtk would not enable qt. This means you can use
> > program-specific flags to choose a specific interface as usual. If
> > multiple component flags are specifically enabled, they all remain
> > enabled.
>
> what is "explicitly"?  is there a clear distinction between
> user-specified (commandline? config-file?) and automatically (somehow)
> added useflags?
"Explicitly" is "you explicitly enabled the flag". Probably in UseFlags.conf, 
perhaps in the system flags or the environment.
>
> Is the purpose here to have implicit decisions that can be overridden by
> specific ones?  So it's basically a hierarchical system?  The advantage
> is that packages define what the useflag means?
The purpose was specifically that packages should *not* define what the flag 
meant - at the moment, there can be a bit of a hodge-podge where different 
recipes choose different meanings for the generic "ssl" flag. We want to make 
that a user preference. It also leads to duplication of configuration within 
the recipe, when with_ssl is defined with the same value as with_gnutls or 
with_openssl.
> Or am I misunderstanding -- is the meaning of "gui" completely defined
> by e.g. "gui: kde qt gtk tk"?
Yes.
> Then that's interesting.  It makes it 
> easier for a system to be unified with one toolkit where possible, I
> guess... probably a desirable thing, but are there really never times
> when it naturally makes sense for different programs to have opposite
> defaults? (license compatibility issues maybe?)...
I don't see license compatibility mattering, but yes, there could be. That's 
why you can override it, or just don't enable +gui if you're using a lot of 
those programs. It's just a convenience, for the case where you definitely 
want to have SSL support in everything, and you prefer GNUTLS if it's 
available. +gnutls +openssl would lead to trying to build with both in 
programs that can use either, which (in general) won't work, so you'd need 
increasingly complex program-specific settings.
> Is it really hierarchical e.g. if there was "gui" already then I could
> hypothetically define something like "interface: cli gui" that says I
> prefer command-line interfaces, but I'd rather have a GUI interface than
> no interface at all, for example? (maybe not all the choices would be
> generic, e.g. "interface: gui ncurses ...")
They are unlikely to be hierarchical (just not worth the trouble to 
implement), and they're not really usefully user-created. There's a fairly 
slim set of flags where it makes sense. SSL library and GUI toolkit were the 
two big examples we came up with.
-Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.gobolinux.org/pipermail/gobolinux-devel/attachments/20080706/366506eb/attachment.pgp