[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.
> 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
Since CONFIG_EXPERIMENTAL is itself a bool, the ambiguity doesn't come
up. But I see your point.
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.
If you really want dep_bool semantics you can still get them:
if_dep CONFIG_EXPERIMENTAL=y
bool 'foo' CONFIG_FOO
fi_dep
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.
> 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.
> 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.
You're probably right. It was just that, since an empty dependency
line evaluates to "y", the syntax for elif falls out pretty much for
free. User perception of total complexity is not free, though, so
I'll probably drop it.
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.
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
