Peter Samuelson wrote: > > [Greg Banks] > > I was thinking that with your proposed syntax we'd have a large > > level of compatibility in both syntax and semantics between "if_dep" > > and "dep_bool", much more so than with "if" and "dep_bool" > > As you said the other day, "This is not a coincidence." (: > > But technically, if_dep corresponds to dep_mbool, not dep_bool.
Yes. > if_dep interprets both 'y' and 'm' as True, just as dep_mbool does. I > considered having 'm' mean False, but in the real world I think > dep_mbool is more useful than dep_bool. Agreed. The common case for testing has y,m on one side and n on the other. > If you really want dep_bool semantics you can still get them: > > if_dep CONFIG_EXPERIMENTAL=y > bool 'foo' CONFIG_FOO > fi_dep Sure, but with something like "if_dep" <-> "dep_bool" and "if_mdep" <-> "dep_mbool" there exists a simple and bidirectional textual rearrangement which completely preserves semantics, to go between using the if and using the dep_*. This means people can safely switch between them without thinking at all. > It is my opinion that most people outside the kbuild-devel list > probably do not understand the difference between dep_bool and > dep_mbool, or if they do understand, they probably do not know for > sure which is which, without looking it up. I don't want to impose > the same learning curve on if_dep. Really, dep_mbool usually *is* > what you want, since it is typically used for sub-features of things > that can be modules. Good point about the learning curve, but I think there is actually less learning curve with two "if_*dep"s because you can say "use an if_dep where you had dep_bool and an if_mdep where you had dep_mbool". > > Yes, you need a condition stack and the else inverts only the top of the > > stack. GCML2 does something like this. > > Yep, that's basically what I did, except that my stack is cumulative > so the 'else' has to handle that. If you made the stack store noncumulative [ymn] results separated by whitespace, it would be trivial to push a new one, pop the stack ("shift") and you could evaluate the cumulative condition with the same function that evaluates a dep condition. Maybe you're doing that already, I haven't read your patch. > Here's an interesting idea which could be powerful but might, once > again, cause too much confusion to be practical: what about an if_dep > variant that has the power to restrict the entire block to {m,n}? > This is the analogue of dep_tristate, and is something the current > if-statement can't do. If set to 'm', it would *not* affect dep_mbool > statements inside the block, but it *would* disable bool and dep_bool, > and restict tristate / dep_tristate to {m,n}. > > This would enable some serious cleanup in e.g. drivers/scsi/Config.in, > where almost every line is individually dependent on CONFIG_SCSI. The > more I think about it, the more useful this starts to sound. This is what ESR did in CML2, with his { } syntax. Inline in a menu, you could do FOO { BAR { BAZ } } which would use the value of FOO to restrict BAR's and BAZ' visibility *and* value, and likewise BAR to restrict BAZ' visibility and value. It was a shorthand syntax for a common case. It's tempting, but perhaps ambitious. Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel