Re: RFC: kconfig select warnings bogus?

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Sat, May 19, 2007 at 04:22:39PM -0700, Andrew Morton wrote:
> On Sun, 20 May 2007 01:05:37 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> 
> > Look for example at the last one in drivers/input/mouse/Kconfig:
> > 
> > config MOUSE_ATARI
> >         tristate "Atari mouse"
> >         depends on ATARI
> >         select ATARI_KBD_CORE
> > 
> > This is perfectly correct (the select'ed symbol is only unavailable when 
> > the dependency can't be fulfilled), and all things to "fix" the warning 
> > will make it worse.
> 
> If ATARI is unset then we shouldn't be generating the "'select' used by
> config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'"
> warnings, should we?

Playing devils advocate here.  What if "ATARI_KBD_CORE" never exists?
Let's say you run 'make kconfig' and you select the ATARI option.  When
does the lack of ATARI_KBD_CORE get noticed and what is the expected
result?

Let's put it another way.  Given the complexities of the configuration
system as it is today, if we do not generate a warning at parse time,
how do we find things like:

config SHARPSL_PM
        bool
        select APM_EMULATION

config PXA_SHARP_C7xx
        bool
        select PXA_SSP
        select SHARPSL_PM

config MACH_CORGI
        bool "Enable Sharp SL-C700 (Corgi) Support"
        depends on PXA_SHARPSL_25x
        select PXA_SHARP_C7xx

and (lets say for the sake of argument) APM_EMULATION were to go away.

Do we really need an exhaustive set of configuration combinations to
run through Kconfig to find possible missing symbols?  Or do we need a
Kconfig lint to find them?

If we're going to make Kconfig warn on missing symbols only when they're
attempted to be selected, you'll have to choose one of those two options.
Choosing none is not an option.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: