Re: non-choice related config entries within choice

[Sam Ravnborg <sam@ravnborg.org>]

On Wed, Jan 16, 2008 at 11:18:38AM +0000, Jan Beulich wrote:
> Roman,
> 
> now that I finally found time to look into the problems that caused the
> patch changing boolean/tristate choice behavior to be reverted I find
> that due to the way things worked in the past there are a couple of
> cases where config options not really belonging to the choice are inside
> the choice scope (drivers/usb/gadget/Kconfig, arch/ppc/Kconfig, and
> arch/mips/Kconfig are where I found such cases, and I hope this is a
> complete list).
> 
> The question is: Is it intended for this to work the way it used to, or
> is it rather reasonable to change these scripts so that stuff dependent
> upon the choice selection is being dealt with outside the choice scope?

Hi Jan.

I will let Roman answer your question..

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.
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.

I just wanted to raise this now that you anyway are looking into choice
related issues.

	Sam