[Kai Germaschewski]
> Well, it'd be nice to first "fix" the dep_* statements so that they
> don't break when that change is done (i.e. in this case, moving
> IDESCSI behind CONFIG_SCSI.
Yes. That's my current plan.
> Basically, extend the "source" command to do a grep CONFIG_* in the
> file to be read and set all found symbols to "n", if unset - only
> then do the actual "source".
Ugly - I'd rather not have to do it that way. (:
> Anyway, some more points:
>
> o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs.
> b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR
>
> (the latter proposed by Peter Samuelson)
>
> I see the following:
> b) needs a large scale patch through all Config.in's. OTOH, it can be
> done step by step, only changing an instance after it has been looked
> at. a) means only a patch to Configure/menuconfig etc, but since it
> changes semantics, it'd be nice to check all possibly breaking usages
> (not too hard thanks to gcml2)
sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case
it is not hard to support both syntaxes - once the transition is
complete, or reasonably complete, we can change the semantics to
'n'=='', which in Configure/Menuconfig can only be enforced in the
non-$ case (well, unless we use your 'source' statement idea).
> I find a) more intuitive, for people who know sh, it's pretty
> clear when we use "$" and when not. Also, for 'if' statements,
> we'll have to use the "$" variant anyway for all I can see, so I
> prefer that from a consistency point of view.
The problem with "intuitive for people who know sh" is that people
think Config.in *is* shell. They start putting in constructs which
are not valid Config.in syntax but which *are* valid sh syntax, so
they work with certain parsers but not others.
Mutating the language, long-term, so that it looks less like sh and
more like a specialised language, is IMO a worthy goal. And I think
it can be done. The main thing to deal with is adding an alternative
syntax for 'if' statements which doesn't look like test(1). More
about that in a separate message.
> a) has the advantage of automatically getting rid of the ugly duplicated
> 'if' tests: (And I think it should allow for getting rid of the
> quotation marks, too)
>
> if [ "$CONFIG_FOO" = "" -o "$CONFIG_FOO" = "n" ]
> --> if [ "$CONFIG_FOO" == "n" ]
> if [ "$CONFIG_FOO" = "y" -o "$CONFIG_FOO" = "m" ]
> --> if [ "$CONFIG_FOO" != "n" ]
See above - 'if' is due for an overhaul as well.
> o whatever we do, having a nice way to handle two exclusive drivers would
> be nice
You mean the case where
A=y implies B=n
B=y implies A=n
A=m implies B<=m
B=m implies A<=m
I agree. Not sure if it needs special casing or just better general
facilities. I think it can be well served by the dep_* !CONFIG_FOO
patch, where !y==n, !n==y, !==y, and !m==m. Then
dep_tristate CONFIG_A !CONFIG_B
dep_tristate CONFIG_B !CONFIG_A
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:33 EST