[Greg Banks] > 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.
I don't envision people switching between dep_* and if_dep. I expect (and hope!) the usual thing will be to switch from if [ ] to if_dep. In which case the current if_dep is what we want, being the more common case. Your proposal is to make if_mdep the common case. Also - consider that most people likely have only a vague idea of when to use dep_bool vs dep_mbool. In that case, automated conversion isn't what you want anyway - the original might be buggy. What you want is for the user to understand WIM. The more I think about it, the more I think the default if_dep should do the m-restricting thing. That way: dep_bool FOO1 BAR BAZ dep_mbool FOO2 BAR BAZ dep_tristate FOO3 BAR BAZ is exactly equivalent to if_dep BAR BAZ bool FOO1 mbool FOO2 tristate FOO3 fi_dep Of course, that requires the invention of 'mbool'. But I do believe it covers most if not all common cases. I guess in this case, though, it's still an open question whether 'define_bool' should be immune from the M effect (like 'mbool') or not. Hmmm. I'm still thinking about this one. > 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. No, it's cumulative, and each 'if_dep' uses the current value to adjust the new value before pushing it. I did it this way because it is more efficient. The 'elif' functionality required some additional complexity, but at your advice I am probably going to drop it in favor of a simple else_dep that takes no arguments. ...But these are implementation details, unimportant at this point. It's a lot more useful to discuss proposed syntax / semantics. Peter ------------------------------------------------------- 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