On Wed, 14 Aug 2002, Peter Samuelson wrote: > I've reused the syntax for a dependency line (the tail end of a > dep_bool / dep_mbool / dep_tristate), like so: > > if_dep <i>dependency line</i> > ... > endif
Honestly, I do not like this. It's probably the best that can be done in shell, but I think it's ugly and not intuitive. > * !CONFIG_FOO negates sense: !y==n, !n==y, !==y, !m==m. The last > !m==m is due to Roman's observation that it is useful to exclude two > things from both being Y while allowing them to both be M. > > * 'or' placed between dependencies functions as a logical OR, and > takes very low precedence. This complements the implicit AND > performed between every pair of dependencies. > > x or x -> x, for any x > n or m == m or n -> m > n or y == y or n -> y > m or y == y or m -> y > > * A=B evaluates to either Y or N, depending on whether A is logically > equivalent to B. It has higher precedence than the ! operator. > Thus: > > CONFIG_FOO=m evaluates to 'y' if CONFIG_FOO is m, 'n' otherwise > CONFIG_BAR=n evaluates to 'y' if CONFIG_BAR is n or empty, 'n' otherwise > !CONFIG_BAZ=y evaluates to 'n' if CONFIG_BAZ is y, 'y' otherwise Hmmh, personally I don't like all these logical operations on tristates, since they are not intuitive (at least for me). They all make sense, and I know we have them in thep dep_* lines already, but I'm not sure we want to spread them further. When we get real tristates for $CONFIG_, every case can be tested for in one comparison (= 'y', = 'm', = 'n', != 'n' etc), and I think the result looks clearer than having to remember the subtleties of a tristate "or". > This syntax is fully backward-compatible. Examples of use: > > if_dep CONFIG_X86 or CONFIG_X86_64 or CONFIG_IA64 > bool 'ACPI support' CONFIG_ACPI > endif > > if_dep CONFIG_SOUND !CONFIG_SOUND_ALSA > source sound/oss/Config.in > endif I don't like this, and I think it is actually the kind of change which is hard to get past Linus, since it just looks ugly. I realize this limitation is largely caused by using shell as the interpreter, but in this case I'd prefer to drop using shell, I think we all agree that a using common parser later would be a good thing anyway, and that really does not need to be written in shell. Just my opinion, of course ;) --Kai ------------------------------------------------------- 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
