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
