2.5 kconfig doesn't handle "&& m" correctly

2.5 kconfig doesn't handle "&& m" correctly

[Adrian Bunk]

Hi Roman,

while looking for the reason for a compile error in 2.5.48 I noticed the
following that seems to be a bug in the new kconfig:

The following is with a .config that was generated using
"make oldconfig":

<--  snip  -->

$ grep SOUND_WAVEFRONT .config
CONFIG_SOUND_WAVEFRONT=y
$ 

<--  snip  -->


sound/oss/Kconfig contains the following:

<--  snip  -->

...
config SOUND_WAVEFRONT
	tristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards"
	depends on SOUND_OSS && m
...

<--  snip  -->


It seems the "&& m" (a common way to ensure that something can only be
built modular) isn't handled correctly.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.5 kconfig doesn't handle "&& m" correctly

[Roman Zippel]

Hi,

On Thu, 21 Nov 2002, Adrian Bunk wrote:

> config SOUND_WAVEFRONT
> 	tristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards"
> 	depends on SOUND_OSS && m
> ...
> 
> <--  snip  -->
> 
> 
> It seems the "&& m" (a common way to ensure that something can only be
> built modular) isn't handled correctly.

Did you disable modules? When modules are disabled tristate symbols are 
treated like booleans, that means they are visible if the dependencies are 
different than 'n'. For this it should be possible to automatically add 
'&& MODULES' if the parser sees a 'm'. I'll have to check this out.

bye, Roman

Re: 2.5 kconfig doesn't handle "&& m" correctly

[Adrian Bunk]

On Thu, Nov 21, 2002 at 01:57:30PM +0100, Roman Zippel wrote:

> Hi,

Hi Roman,

> On Thu, 21 Nov 2002, Adrian Bunk wrote:
> 
> > config SOUND_WAVEFRONT
> > 	tristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards"
> > 	depends on SOUND_OSS && m
> > ...
> > 
> > <--  snip  -->
> > 
> > 
> > It seems the "&& m" (a common way to ensure that something can only be
> > built modular) isn't handled correctly.
> 
> Did you disable modules? When modules are disabled tristate symbols are 

yes, this was with a .config without modules support.

> treated like booleans, that means they are visible if the dependencies are 
> different than 'n'. For this it should be possible to automatically add 
> '&& MODULES' if the parser sees a 'm'. I'll have to check this out.

My first thought is that this sounds like a workaround. Is there a good
reason not to restore the semantics of the old kconfig that interpreted
dependencies as a restriction of the input range?

> bye, Roman

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.5 kconfig doesn't handle "&& m" correctly

[Roman Zippel]

Hi,

On Thu, 21 Nov 2002, Adrian Bunk wrote:

> > treated like booleans, that means they are visible if the dependencies are 
> > different than 'n'. For this it should be possible to automatically add 
> > '&& MODULES' if the parser sees a 'm'. I'll have to check this out.
> 
> My first thought is that this sounds like a workaround. Is there a good
> reason not to restore the semantics of the old kconfig that interpreted
> dependencies as a restriction of the input range?

It still does mostly, that's one case I missed. The old config had more 
than one semantic regarding visible input range (the shell 'if' semantic 
and the dep_* dependencies, which differed again between the commands), 
kconfig has only one. So it's not matter of restoring semantics, but 
translating them correctly. In general a symbol is now visibile is if the 
dependencies are !='n', "restoring" would mean to change this into ='y' 
only for tristate symbols when MODULES='n', this would be an even larger 
hack. Translating 'm' into 'm && MODULES' is the cleaner solution, as it 
doesn't change the base kconfig logic.

bye, Roman