Re: [patch] config language dep_* enhancements

[Peter Samuelson]

[Greg Banks]
> I like the basic idea here, and I'm pleased that someone has the
> courage to tackle some of the brokenness of the kconfig language (if
> only because it will provide me with a precedent when I try to
> submit some of my patches ;-).

Thanks for the feedback. (:

> > This applies to 2.4.20pre and (except changelog bits) to 2.5.30 with
> > offsets.  
> 
> You're willing to potentially perturb 2.4?

This stuff is trivial enough, and easy enough to test, that I think it
could go in 2.4, yes.  Obviously xconfig would need to be dealt with
in sync with the others, which I'm not doing during the prototyping /
idea-mongering stage.

> The last statement is inconsistent with the shell code and the
> explanations of the dep_* statements, which sensibly preserve the
> current semantics where an undefined symbol has a distinct fourth
> value which is not y, m or n.
> 
> I'm pleased to see that you have preserved those semantics.  There
> are many places in the corpus where a dep_* lists as a dependency a
> variable which is not defined until later, or is only defined in
> some architectures, or is never defined.  Earlier today I tweaked up
> gcml2 to detect them and found 260 in 2.5.29.

You give me too much credit.  The main motivation for dropping the '$'
was to make possible the "" == "n" semantics.  That the patch failed
to do so was accident, not design.

I know the current behavior is documented, but I had thought this was
because changing the behavior was not feasible due to our Bash-based
"JIT parsers".  Can you provide a rationale for why the current
behavior is desirable?  It seems to me that it only encourages buggy
Config.in code (since "" == "n" in other contexts like the #defines),
and I don't see any benefits other than that it's the status quo.

[Not to demean the status quo - in 2.4 it is probably appropriate.]

> > +    In addition, the /dep/ may have a prefix "!", which negates the
> > +    sense of the /tristate/: "!y" and "!m" reduce to "n", and "!n"
> > +    reduces to "y".
> 
> Perhaps "negates" isn't quite the right word in four-state logic.

I wasn't sure what else to call it.  Besides, as explained above, it's
intended (rightly or wrongly) to be 3-state logic, where two states
represent a form of "true". (:

Perhaps "the /dep/ may have a prefix "!", which transforms the
/tristate/ as follows: ..."  This is particularly appropriate in light
of Roman's argument (which I buy) in favor of "!m" == "m".

> > +function dep_calc () {
> > +       local neg arg
> > +       cur_dep=y       # return value
> > +       for arg; do
> > +         neg=;
> > +         case "$arg" in
> > +           !*) neg=N; arg=${arg#?} ;;
> > +         esac
> > +         case "$arg" in
> > +           y|m|n) ;;
> > +           *) arg=$(eval echo \$$arg) ;;
> 
> Don't you want to check at this point that arg starts with CONFIG_?
> Also, how about quoting \$$arg  ?

I suppose one could add sanity checks / diagnostics, but there are no
other valid cases, so that's all they would be.  I'm not really trying
to produce a config.in 'lint' - leave that to the static parsers like
gcml2, xconfig and mconfig.

Peter