[Peter Samuelson]
!y == n
!m == n
!n == y
[Roman Zippel]
I would define !m as m, e.g. it would allow
dep_tristate CONFIG_OLD !$CONFIG_NEW
dep_tristate CONFIG_NEW !$CONFIG_OLD
You know, that never even occurred to me. Your scheme is not strictly
logical, but it is much more practical, since it is perfect for
expressing a relatively common (and currently awkward) case.
I'm convinced. Now we have
!y == n
!m == m (significant for dep_tristate and dep_mbool)
!n == n
BTW, does anyone have a problem with my proposal (for 2.5, not
necessarily 2.4) for '/dep_/s/ \$CONFIG/ CONFIG/g' ? That is,
-dep_tristate CONFIG_FOO_X CONFIG_FOO CONFIG_BAR !CONFIG_BAZ
+dep_tristate CONFIG_FOO_X $CONFIG_FOO $CONFIG_BAR !$CONFIG_BAZ
Advantages:
- the config files are more readable, especially when using !
- can support the old syntax with no extra code
and most importantly
- resolves the parsing difficulty with detecting an undefined value
in dep_* statements. Currently the undefined value is documented as
ignored, but try to avoid the situation.
which leads to
- allows us to drop all those 'define_bool CONFIG_FOO n' statements
whose main purpose was to avoid the empty value
Eh? I posted a patch earlier; it was trivial, despite having a syntax
error in Configure (deleted a 'while...do', forgot the 'done') which
only proves that I don't test stuff very rigorously. Menuconfig
actually shrunk, due to factoring. If and when I get my head around
xconfig, we'll see how ugly this stuff does or doesn't get, but then
again, if xconfig were made uglier, would anyone notice?
Peter
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
