From: Bernd Petrovitsch <bernd@firmix.at>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: kconfig - a suggestion how to fix the select issue
Date: Sun, 04 May 2008 12:12:02 +0200 [thread overview]
Message-ID: <1209895922.4114.21.camel@gimli.at.home> (raw)
In-Reply-To: <20080504071041.GA15315@uranus.ravnborg.org>
On Sun, 2008-05-04 at 09:10 +0200, Sam Ravnborg wrote:
> Today we have two ways to express/solve dependencies.
>
> Top-down we have "depends on"
> and bottom up we have "select".
>
> The "depends on" dependencies at the same
> time impact the visibility of a symbol.
> A symbol with "depends on" not satisfied are not
> visible and thus not shown in menuconfig.
Perhaps this is problem: The menu item shouldn't be selectable for sure
but it may well be visible (and I'm purposely ignoring details of "how
to grey out" for the different user interfaces).
If it's visible (but not selectable) the user interface can provide the
auto-generated requirements (derived from the "depends on" chains) as
part of the "help" or where ever it seems useful. And the user at least
knows where to look further.
> The "select" method is a way to forcefully
> set the selected symbol to the same value
> as the one where the select are stated.
Which makes sense from the usability point of view for typical library
functions (e.g. zlib, CRC, ...).
But that ("which CONFIG_ variables actually selected this CONFIG_
variable" and/or "which CONFIG_ variables will selected this CONFIG_
variable") could also be automatically generated and displayed.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
next prev parent reply other threads:[~2008-05-04 10:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-04 7:10 Sam Ravnborg
2008-05-04 8:11 ` Adrian Bunk
2008-05-04 8:27 ` Sam Ravnborg
2008-05-04 9:04 ` Adrian Bunk
2008-05-04 10:38 ` Sam Ravnborg
2008-05-04 11:55 ` Adrian Bunk
2008-05-04 12:17 ` Sam Ravnborg
2008-05-04 12:57 ` Adrian Bunk
2008-05-04 12:37 ` Oleg Verych
2008-05-04 10:12 ` Bernd Petrovitsch [this message]
2008-05-04 17:59 ` Matthias Schniedermeyer
2008-05-04 12:55 ` David Collier-Brown
2008-05-04 15:01 ` Oleg Verych
2008-05-04 19:28 ` Rene Herman
2008-05-04 19:32 ` Sam Ravnborg
2008-05-04 20:14 ` Bernd Eckenfels
2008-05-06 8:19 ` Jan Engelhardt
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=1209895922.4114.21.camel@gimli.at.home \
--to=bernd@firmix.at \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=zippel@linux-m68k.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®