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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
