On Monday 22 April 2013 16:26:49 Yann E. MORIN wrote: > On Mon, Apr 22, 2013 at 02:19:50PM -0400, Mike Frysinger wrote: > > On Monday 22 April 2013 14:00:46 Yann E. MORIN wrote: > > > As far as I remember, this has always been the behaviour of menuconfig. > > > > > > What do you suggest the frontends do in this case, short of re-ordering > > > the options (which I think is not correct) ? > > > > i think you missed a critical part of my proposal: > > seems like *if a node is unprintable*, it should get skipped for > > menuconfig purposes > > Ah, yes, I missed it. And it is part of the solutions I exposed, too: > > On the other hand, we could consider dependent options as candidates > for being sub-options until we see the first non-dependent option with a > prompt. > > > to modify your example, i'm proposing a change for: > > menuconfig MENU_A > > bool "A" > > > > config OPT_B > > bool > > > > config OPT_C > > bool "C" > > depends on MENU_A > > > > OPT_B is not shown to the user (there is no option text), therefore it > > should automatically get skipped when searching for options to collapse > > into the menuconfig MENU_A. > > > > i do agree that if OPT_B had text, then the existing behavior would be > > unchanged. > > And as I pointed out, this would break as soon as an option with a prompt > (which you call 'option text') is added in-between. For example, starting > with: sure. i'm focusing on the non-displayed case since it wouldn't be a behavioral change, and because that's the only reason that EXPERT broke. there aren't EXPERT & non-EXPERT options there (at least, unintentional). i don't think we should worry about this case because, as you pointed out, we already have kconfig language to enforce the behavior if truly desired. using the EXPERT case as an example, i don't think we want the re-ordering as this is a general knob. we've got specific items which make more sense when grouped elsewhere, and we've got a "dumping bucket" which the current EXPERT menuconfig is designed to hold. for example, checkpoint/restore makes more sense when grouped with cgroups/namespace (and it actually appears *before* the EXPERT menuconfig, so you'd have to build the entire tree first before doing possible re- ordering/processing). another example, the vmcounters/slub debug better fits with the non-expert memory settings (like "choose your allocator"). > This would change the semantic of the language anyway, where currently > your example disrupts the dependendcy chain. Granted, it looks like a > good change, but I think we should not encourage people to be lazy, and > we better want them to be careful about what they intend to do, about > what they review and ack (myself largely included! :-] ). sure, but i think we can segment this. i don't think we should hassle developers with details that make 0 difference to the end result. that's why i think automatically handling options that don't get displayed is OK. but resorting options and possible sticking them in different menus than what the source Kconfig files declare violates KISS. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
