[U-Boot] Kconfig menu layout (multiple ways to show the same Kconfig configs?)

[Kumar Gala]

On May 1, 2009, at 6:47 AM, Sam Ravnborg wrote:

> On Wed, Apr 22, 2009 at 07:44:48AM -0500, Kumar Gala wrote:
>>
>> On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
>>
>>> Dear Kumar Gala,
>>>
>>> In message <93A8F58D-8C13-4F72-AFF3-
>>> CF4FDF9A3CFA at kernel.crashing.org> you wrote:
>>>>
>>>>> In my experience, I tend to search for board names first.
>>>>
>>>> So back to the root of my question, do we just have one really long
>>>> list of board names?
>>>
>>> I'm not an expert for the capabilities of Kconfig, but one looong  
>>> list
>>> with hundrets of entries clearly makes no sense. We obviously need  
>>> sum
>>> grouping / structuring.
>>>
>>> IMHO there should be several options:
>>>
>>> - for those who look for a board name, we should support this,
>>> probably wih an initial selection by the first letter (case
>>> insensitive) of the board name.
>>>
>>> like this:	=> board name => M => MPC837XERDB
>>>
>>> - alternatively, it should be possible to restrict the choice by
>>> selecting first processor architecture (ARM, PowerPC, MIPS, ...),
>>> then CPU (family) name, then board names.
>>>
>>> like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB
>>
>> Sam,
>>
>> We are looking at moving u-boot to use Kconfig and was wondering if
>> you could possible tell us if its possible to represent the same
>> Kconfig 'config' options via two different menu schemes.  We have a
>> list of boards that will be 'config' options.  We'd like to have it  
>> in
>> one 'menu' that is just a long list of boards.  The other would be a
>> smaller subset that you "filter" based on selecting an Arch &  
>> Subarch.
>>
>> is something like this possible?
>
> Hi Kumar.
>
> Was my input useable or just pure rubbish?

Its usable.. one question I had was if you ever gave thought to having  
a 'config' type that was only for internal dependencies and didn't  
show up in the resulting .config.

- k