Re: RFC: kconfig select warnings bogus?

[Trent Piepho <xyzzy@speakeasy.org>]

On Sun, 20 May 2007, Stefan Richter wrote:
> Trent Piepho wrote:
> > config A
> > 	bool "A"
> >
> > config B
> > 	bool "B"
> > 	depends on A
> >
> > config C
> > 	bool "C"
> > 	select B
> >
> > In this case, it's possible to turn C on and A off.  B will be on, even
> > though it depends on A and A is off.
> >
> > The kconfig docs say that "B..  depends on A" sets the maximum value of B
> > to be that of A.  Since A=0, the max value of B is 0.
> >
> > The kconfig docs also say that "C..  select B" sets the minimum value of B
> > to be that of C.  Since C=2, the minimum value of B is 2.
> >
> > So we have B>=2 and B<=0, which is obviously impossible.  Yet *config has
> > no problem with this, and will set B=2 even the 'depends' means B must be
> > 0.  It seems like "select" will override any other dependencies.
>
> If that's so, then we have /a/ an incomplete definition of the Kconfig
> language (what is supposed to happen if "select" attempts to set an
> impossible value?) and /b/ a bug in the make xyzconfig programs (they
> generate invalid configs).

This came up when I was working on the v4l-dvb tree's out of kernel build
system.  It uses the same Kconfig files, but I've created a config system in
perl to parse and evaluate them.  It will disable options that the kernel
config programs allow, and it is because I'm treating this situation
differently:  Since "B" is disabled because "A" is off, "C" must also be
disabled.

Another way of dealing with this would be to have 'select' follow the
dependency chain back up.  Turning on C selects B, B depends on A, so A is
also selected.

One problem with this is that "depends on" can take complex expressions.
Finding the solution is NP complete, which likely isn't a problem for the
sizes of realistic Kconfig files.  But there could easily be multiple
solutions, so which one is the right one?