From: Mike Frysinger <vapier@gentoo.org>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: linux-kbuild@vger.kernel.org
Subject: Re: non-visible options vs menuconfigs
Date: Mon, 22 Apr 2013 14:19:50 -0400 [thread overview]
Message-ID: <201304221419.51623.vapier@gentoo.org> (raw)
In-Reply-To: <20130422180046.GA24143@free.fr>
[-- Attachment #1: Type: Text/Plain, Size: 2168 bytes --]
On Monday 22 April 2013 14:00:46 Yann E. MORIN wrote:
> On Mon, Apr 22, 2013 at 12:51:53PM -0400, Mike Frysinger wrote:
> > the current EXPERT menuconfig is broken by some new options that happen
> > to be sprinkled into the wrong place. seems like if a node is
> > unprintable, it should get skipped for menuconfig purposes ? otherwise,
> > this is a constantly losing battle where someone inserts new Kconfig
> > options and forgets this nuance, and then it stays broken for a while
> > until someone notices. this particular bug wrt EXPERT has been
> > linux-3.2.
> >
> > for example, in the General setup section, you currently see:
> > [ ] Configure standard kernel features (expert users) --->
> > [ ] Embedded system
> >
> > if you enable EXPERT there, the options get dumped into the same level
> > instead
> >
> > of being under that menuconfig:
> > [*] Configure standard kernel features (expert users) --->
> > [ ] Sysctl syscall support
> > [*] Load all symbols for debugging/ksymoops
> > ...
> > [ ] Embedded system
>
> Yes, this is indeed disturbing.
>
> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
> > is this feasible in the kconfig code ?
>
> From Documentation/kbuild/kconfig-language.txt:
when i said "kconfig code", i was referring to making changes to the parsing
source, not the kconfig language.
> 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
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.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-04-22 18:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-22 16:51 non-visible options vs menuconfigs Mike Frysinger
2013-04-22 17:08 ` Randy Dunlap
2013-04-22 18:03 ` Mike Frysinger
2013-04-22 18:00 ` Yann E. MORIN
2013-04-22 18:19 ` Mike Frysinger [this message]
2013-04-22 20:26 ` Yann E. MORIN
2013-04-22 21:12 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201304221419.51623.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=yann.morin.1998@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.