Messages in this thread | | | Subject | Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert | From | Paul Bolle <> | Date | Tue, 12 May 2015 00:01:27 +0200 |
| |
On Mon, 2015-05-11 at 14:47 -0700, Josh Triplett wrote: > On Mon, May 11, 2015 at 11:32:28PM +0200, Paul Bolle wrote: > > Is squashing those two lines worth a new kconfig mechanism? > > In my opinion, yes. If you use the implicit (and error-prone) > menuconfig submenuing, you get a single entry with the '[ ]' and the > submenu. There are currently 272 instances of "menuconfig" in Kconfig > files.
How many of those use the subtle trick EXPERT uses?
> I'd like to have a less error-prone mechanism for people to use, > with an explicit "endmenu" at the end, and I don't want to leave any > incentive for people to need the more error-prone version. > > I would be tempted to just make "menuconfig" require an endmenu, and > convert all users, but that would almost certainly break many > third-party users of kconfig. So instead, I'm currently extending > "menu" (which already expects "endmenu") to allow the syntax > "menu config SYMBOL", which acts like a combination of "config SYMBOL" > and a menu with "visible if SYMBOL".
Bikeshedding (before I'm even convinced of the need of this extension): "menu config" is far too similar to "menuconfig".
> Diffstat for the patch I'm testing > right now: > > scripts/kconfig/zconf.y | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > That seems worthwhile to have a less error-prone menu mechanism. > > (The actual patch would also need to updated zconf.tab.c_shipped.)
And some lines in Documentation/kbuild/kconfig-language.txt (speaking from memory).
> (Also, the diff you posted would be smaller if you left "config EXPERT" > at the top of init/Kconfig.expert; why the move?)
It was a quick hack. I didn't gave the move much thought, to be honest.
Thanks,
Paul Bolle
| |