Peter Samuelson wrote:
>
> Greg, in regards to another question you had - no I don't think there
> is value in having a variant if statement that treats 'm' differently.
> You can already get the same effect by using 'CONFIG_FOO=y' or
> 'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
>
> You are much better than I at finding examples of weird stuff in the
> config system, though, so let me know if this doesn't cover all cases.
No specific cases, but 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", so people would be tempted to start moving code between
them, e.g. changing backwards and forwards between
if_dep CONFIG_EXPERIMENTAL
bool 'foo' CONFIG_FOO
fi_dep
...and...
dep_bool 'foo' CONFIG_FOO CONFIG_EXPERIMENTAL
(correct me if I misunderstand the thrust of the proposal). Eventually
someone would want to do this kind of trick with a "dep_mbool" and complain,
or more likely the rules would break subtly.
> [I wrote]
> > else_dep() is a simple matter of reversing the polarity of the guard.
>
> No it's not - I just realised that this breaks nested if_dep.
Yes, you need a condition stack and the else inverts only the top of the
stack. GCML2 does something like this.
> > I suppose Bourne-feature-completeness would demand 'elif_dep' as
> > well.
>
> I also realised that else_dep and elif_dep are exactly the same except
> that else_dep doesn't take a dep line. So else_dep now does double
> duty:
I don't see any value to adding an else-if ability. Like parentheses in
"if_dep" expressions, it's more complexity than is justified by the logic.
> Incremental patch (lightly tested) over the one earlier in the thread:
I'll look at this later,
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
