Re: kconfig - a suggestion how to fix the select issue

[Sam Ravnborg <sam@ravnborg.org>]

On Sun, May 04, 2008 at 12:04:29PM +0300, Adrian Bunk wrote:
> On Sun, May 04, 2008 at 10:27:32AM +0200, Sam Ravnborg wrote:
> > On Sun, May 04, 2008 at 11:11:45AM +0300, Adrian Bunk wrote:
> > > On Sun, May 04, 2008 at 09:10:41AM +0200, Sam Ravnborg wrote:
> > > >...
> > > > 
> > > > config A
> > > >         bool "a"
> > > > 
> > > > config B
> > > >         bool "b"
> > > >         depends on A
> > > > 
> > > > config C
> > > >         bool "c"
> > > >         require B
> > > > 
> > > > The require dependency will have impact on visibility.
> > > > C shall only be visible if all symbols it require are
> > > > visible. Note that visible does not imply 'chosen'.
> > > > In this case C would be visible when A is chosen.
> > > > 
> > > > When the user then choose C and B is not chosen 
> > > > then the user is prompted to choose B.
> > > > 
> > > > So user has to chose B in order to have C chosen.
> > > >...
> > > > Comments?
> > > 
> > > 
> > > Given:
> > > 
> > > config A
> > > 	tristate "a"
> > > 
> > > config B
> > > 	tristate "b"
> > > 	depends on A
> > > 
> > > config C
> > > 	bool "c"
> > > 	require B
> > > 
> > > CONFIG_A=m
> > > 
> > > 
> > > Will C be visible?
> > If you followed my description then you would see
> > that the visibility of C are determineded by the dependencies
> > of C (none in this case) and the dependencies of the symbol
> > it requires. In this case B. B dpens on A and A equals m so B is
> > visible thus C is visible.
> 
> *shudder*
So let me explain it with some other words:
B is visible because A=m
C is visible because B is visible.
Simple.

> 
> > > The underlying problem is that we use bool for two different cases:
> > > - non-modular driver (answer would be "no")
> > > - enable feature in driver (answer would be "depends on the value of D")
> > Lets try to agree on the semantics with bools first please.
> > When we have that in place lets extend it to modular - OK?
> 
> I doubt the "extension" works this way since most of the interesting 
> cases are with tristates.
> 
> But OK, here's some fun with bools:
> 
> config X86
> 	def_bool y
> 
> config A
> 	bool "a"
> 
> config B
> 	bool "b"
> 	depends on A
> 
> config D
> 	bool "d"
> 	depends on !B if X86
> 
> config E
> 	bool "e"
> 
> config C
> 	bool "c"
> 	depends on D || E
> 	requires B
> 
> Given:
> - CONFIG_A=y
> - CONFIG_B=n
> - CONFIG_D=y
> - CONFIG_E=n
> 
> Will C be visible?
The above has a syntax error. A 'depends on' cannot have an
if caluse.
And I did not get your point either.

Are you trying to say that we cannot improve kconfig to better
express the dependencies or what is your point?

Puzzeled...

	Sam