[kaos] > If you assume that config1 is always boolean then order does not > matter. If config1 is tristate then order does matter. > > config1 config2 objects > y y y > y m m > m y y <=== config2 controls > m m m
OK, yes, this is different. The question becomes, which would be the desirable semantics? Most of the time, having multiple config variables means all but one would be bool, but if someone wants to control an object file with more than one tristate variable -- I assumed that in such a case, *any* 'm' should imply a 'not y' result. I assert that this is reasonable for Least Surprise. (And I know I don't have to tell you about Least Surprise, since the kernel hackers are having to learn a whole new set of macros here.) Can you think of a realistic example of having two tristate variables, one of which is set to 'm' and the other to 'y', and wanting the dependent object file compiled as 'y'? Because I can't. > I agree that select() should be extended to take multiple config > options, with at least one being required. Cool. Peter _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
