[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
