Hi all, There's been some lengthy discussion on #gobolinux about these, and whether or how they should be implemented.
A term: a generic flag is a flag pertaining to a concept, rather than a specific program or option, that may be fulfilled multiple ways. ssl would be one example (fulfilled by gnutls or openssl); gui would be another (kde, qt, gtk, tk, fltk, ...). A component flag is one of those fulfilling flags of a generic flag. The problems with these are threefold: first, they necessarily involve duplication of configuration inside the recipe; secondly, they can come into conflict with their own components; and thirdly, the choice of which to default to falls down to the recipe author's level, rather than being a user preference. All of those lead to a more complicated system and increasingly complex recipes. The proposed solution to this is to have special treatment for these generic flags, with an order of preference. There would be a file with a list of component flags - gui: kde qt gtk tk. When the gui flag was enabled, the first-listed flag in that list that was supported by the recipe would be implicitly enabled. Compiling Pidgin would implicitly enable +gtk for the recipe. 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. The generic flag would remain enabled, for the occasional case where you have duplicated work across a whole set of related flags. For that same purpose, any one of the component flags specified directly would implicitly enable the generic flag within the recipe. The hook functions and with_generic variable would always be available no matter how the flag was enabled. Now, here comes your part in all this: tear the preceding to pieces and show us why it's wrong. -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
