[Kai Germaschewski]
> 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.
I accept that it is not pretty. But unless we can switch to mconfig
or gcml2 or some other static parser for everything, we will need
shell-parsable syntax. And I submit that the current pseudo-shell
syntax using if [ ] is quite a bit uglier and less intuitive.
The shell-syntax if [ ] might seem intuitive at first glance, if you
already know the Bourne shell, but that leads you into the trap that
you can use *any* Bourne shell syntax there, which of course you
can't. For example, someone might try the following:
if [ "$CONFIG_FOO" = "y" ] || [ "$CONFIG_BAR" = "y" ]; then
or perhaps, being ksh wizards, they think they can use
if [[ $CONFIG_FOO = y || $CONFIG_BAR = y ]]; then
Oops.
By using *exactly* the same syntax for dep_* and if_dep, I hope to
*reduce* the confusion of exactly what functionality is or is not
available. Currently we have a *completely arbitrary* subset of
Bourne shell and /bin/test, which is Not Good.
It is also, I believe, easier to implement a static parser for my 'if'
replacement, since the dependency line bit can share common code. My
Menuconfig patch illustrates this.
> > 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).
Note that the 'if_dep' statement is effectively boolean anyway, so the
dependency line gets implicitly cast to bool, just as with dep_mbool.
So the fact that 'm' is distinct from 'y' is really only important for
dep_bool and dep_tristate. If people want to avoid using ! or 'or' or
the '=x' suffix in dep_bool and dep_tristate lines - well, they've
been getting along fine without them for years.
This is similar to the fact that you can mix and match '-o' and '-a'
in our current if statements, but the precedence rules are unclear, so
nobody ever actually does it. We use nested 'if' statements instead.
As for the ! operator, I originally suggested that !m==n, but it was
pointed out to me that !m==m is more practical, since it corresponds
to a common case in config code.
In these Boolean relations there is more than one truth value - but
note that the same is true in C. !!x does not in general yield x, and
I don't think this confuses most people.
> 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.
It's the cleanest syntax I can come up with - including the status
quo, which if you didn't know it was supposed to be an imitation of
Bourne shell, would look completely bizarre.
Perhaps you prefer the status quo, for the simple reason that if we
have to have something ugly it may as well be a *familiar* ugliness.
That is a vald argument, though I disagree with it. Or do you have an
alternative new syntax to propose?
> 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".
I don't follow. What do you mean by "real tristates for $CONFIG_"?
> > 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.
Once again, we're comparing the above against
if [ "$CONFIG_X86" = "y" -o "$CONFIG_X86_64" = "y" -o \
"$CONFIG_IA64" = "y" ]; then
bool 'ACPI support' CONFIG_ACPI
fi
if [ "$CONFIG_SOUND" = "y" -o "$CONFIG_SOUND" = "m" ]; then
if [ "$CONFIG_SOUND_ALSA" != "y" -a "$CONFIG_SOUND_ALSA" != "m" ]; then
source sound/oss/Config.in
fi
fi
> 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.
If we can get mconfig or similar into the standard kernel and displace
Configure and Menuconfig, we'll certainly have a lot more options. I
agree that it would be nice to drop the requirement for shell parsing.
I just don't know if it's a realistic goal, especially before 2.6.
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
