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

[Masahiro Yamada]

2018-03-03 18:34 GMT+09:00 Ulf Magnusson <ulfalizer@xxxxxxxxx>:
> 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).

We could also revert 3b9a19e08960e5cd.  :)


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

I am happy to drop this test
if removing the seem-to-work feature will clean up the code.


Now I am accumulating test cases.



-- 
Best Regards
Masahiro Yamada