lkml.org 
[lkml]   [2008]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kconfig - a suggestion how to fix the select issue
> > > > > 
> > > > > 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.
>
> I understand what you are saying.
>
> The problem is that with A=m, C=y built-in code enabled by C cannot
> access the code enabled by A which can result in a build error.

That is a different type of issue which would most likely
be solved by a "depends on A == y"

> > > 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.
>
> I know I'm bad at the syntax when I'm not trying stuff myself.
> depends on !B || !X86
> is the same and should be the correct syntax.
>
> Or make it just
> depends on !B
>
> The problem is not the syntax, the problem is whether C should be
> visible, and what happens if the user enables it.
OK - lets analyse this.
B is visible (because A is y)
D is visible (because B is n)
E is visible

So per the definition C is visible.
If user choose 'C' then user will be prompted to choose B
due to the "require B".
User now set B equal to 'y' and we have following situation:
B is visible (because A is y)
D is invisible (because B is y)
E is visible
So per definiton C is still visible.
So user is now prompted to chose C.


On the other hand had we had a:
config C
bool "c"
depends on D
requires B

Then when user set B equal 'y' user no longer
are offered the possibility to chose 'C' as it is no
longer visible.

> >
> > Are you trying to say that we cannot improve kconfig to better
> > express the dependencies or what is your point?
>
> My point is that all this "select follows depenencies" is easily said,
> but doing it in a way that it's better than what we have today is
> nontrivial.
Which is exactly why I try to involve you in the discussion
of a potential solution.

Sam


\
 
 \ /
  Last update: 2008-05-04 14:19    [W:0.058 / U:6.876 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site