> > > > > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
