Re: [PATCH v2 09/11] kconfig: unittest: test randconfig for choice in choice

[Ulf Magnusson]

On Fri, Mar 2, 2018 at 10:29 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
>
>
> On Fri, Mar 2, 2018, 3:14 AM Ulf Magnusson <ulfalizer@xxxxxxxxx> wrote:
>>
>> On Fri, Mar 2, 2018 at 5:31 AM, Masahiro Yamada
>> > This is complicated usage, but it is still used in the real world;
>> > drivers/usb/gadget/legacy/Kconfig is source'd in a choice context,
>> > then creates a sub-choice in it.
>>
>> That file is the only one that does all that weird choice stuff btw.
>>
>> It's as if it was written to make use of as much obscure Kconfig stuff
>> as possible. :P
>
>
> Can't we just use another way to describe this requirement on this file,
> with the trade-off of simplifying kconfig semantics?
>
>   Luis

I don't think changing how drivers/usb/gadget/legacy/Kconfig does
things would allow for any simplifications, unfortunately (except to
get rid of the fix tested by this patch, maybe).

Being able to have non-choice-value symbols and choices in choices is
a side effect of automatic submenu creation. Symbols and choices that
depend on the symbol before them end up in a submenu, and only the
top-level symbols in the choice are marked as choice value symbols.

I always wondered whether that was an intended feature or just
something people discovered works (it seems to work anyway...). It
feels pretty iffy to have cosmetic submenus affect behavior like that,
but playing devil's advocate, it kinda makes sense to put symbols
close to the symbols they depend on if you can get away with it.

Cheers,
Ulf