On Mon, Sep 22, 2008 at 9:50 AM, Carlo Calica <[EMAIL PROTECTED]> wrote: > On Sun, Sep 21, 2008 at 2:35 AM, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >> Hope to get some input on this and in the end come to a consensus. > It seems the two states of set and unset aren't enough. How does > adding a third state (on, off, neutral) affect things? Badly.
It isn't "neutral", it's "off", and there's a third state "no, I really mean it, off" that prevents it coming in from a generic. It doesn't actually disable anything, though, so configure may still run against it (so it doesn't give those people what they want either, but it looks like it does from a distance). It's not an improvement, it's added complexity and confusion for no gain. The solution to this "problem" is that you don't enable generic flags you don't want to use, and you don't list programs you don't want to use as part of the generics you *do* want to use. If you want to use a specific implementation for a particular program, you enable that implementation for that program. There is no case that isn't already covered. >> "aaa: bbb ccc ddd" > Are bbb, ccc, ddd mutually exclusive? I don't think that is a > reasonable assumption. Some apps can do runtime selection of the > specific implementation. Others can't. They may be mutually exclusive. The generic never selects more than one of them (the first-listed one that is specified as usable in the program's Dependencies file), but you can enable as many as you like and they will be given to the recipe to do as it wishes with. If they're mutually exclusive, the behaviour depends on the program's build system - you'll probably either get a failure or whichever ends up being the last one in the ./configure arguments. This part isn't an issue. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
