Re: non-choice related config entries within choice

[Sam Ravnborg <sam@ravnborg.org>]

On Wed, Jan 16, 2008 at 01:46:57PM +0000, Jan Beulich wrote:
> >But one feature I really would like to see is named chocies so we can do stuff like:
> >
> >choice X86_PROCESSOR
> >
> >config GENERIC_PROCESSOR
> >	bool "A generic X86 processor"
> >endchoice
> >
> >
> >...
> >
> >choice PPC_PROCESSOR
> >
> >config GENERIC_PROCESSOR
> >	bool "A generic PowerPC processor
> >
> >endchoice
> >
> >The issue here is that we do not today allow the same config option
> >to appear if more than one choice.
> 
> I want named choices, too, but for a different purpose (and not
> unconditionally): Currently, a choice really can just be a selection
> between individual boolean settings or (as the current intended
> extension) a mixture of boolean and tristate values. String or
> numerical values aren't permitted (and iirc they even cause the config
> process to crash). Nevertheless there are a couple of example where
> choosing between individual string or numeric values is intended (but
> needs to be made work with the current infrastructure, meaning that
> one first chooses between boolean values and then selects (or sets
> through default values in prompt-less config options) the intended
> string or numeric value.
> 
> What you want seems much more fundamental a change, and as I
> understand it you really want the name just as a name space
> separation mechanism.
> 
> >This is a mandatory feature before we can do a Kconfig covering all architectures.
> >I guess there are other issues when we do:
> >
> >if X86
> >source foo/bar/Kconfig
> >endif
> >
> >if PPC
> >source foo/bar/Kconfig
> >endif
> >
> >Where we in foo/bar/Kconfig has a choice list.
> 
> That you be done with
> 
> if X86 || PPC
> source foo/bar/Kconfig
> endif

The problem is that the two source happens in different places as they
are part of a menu structure. So the Kconfig files cannot easily be refactored
to use a sinlge source per file.

	Sam