Re: [patch] config language dep_* enhancements

[Peter Samuelson <peter@cadcamlab.org>]

[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