public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Roman Zippel <zippel@linux-m68k.org>,
	linux-kbuild <linux-kbuild@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: kconfig - a suggestion how to fix the select issue
Date: Sun, 4 May 2008 09:10:41 +0200	[thread overview]
Message-ID: <20080504071041.GA15315@uranus.ravnborg.org> (raw)

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.

The "select" method is a way to forcefully
set the selected symbol to the same value
as the one where the select are stated.

But this has shortcoming in relation to the
interface we like to present to the user.

Consider following example:

config A
	bool "a"

config B
	bool "b"
	depends on A

config C
	bool "c"
	depends on B

To be able to chose 'C' I have to chose
A and then B before I am even offered 
the possibility to chose 'C'.
And this is often less than obvious. C could
be a device that uses either USB or firewire
and I could not care less.

The usual way to solve this is to introduce
use of select like this:

config A
	bool "a"

config B
	bool "b"
	depends on A

config C
	bool "c"
	select B     <= use of select

With this change we have increased visibility
of C so it is shown in menuconfig.
But if we chose 'C' then we implicitly set
B='y' too but ignore the dependency of 'A' so
we end up with a configuration where:
A='n'
B='y'
C='y'
which is not what we wanted. As B depends on A we should
never see B equals 'y' when A equals 'n'.

The solution is not to let "select follow dependencies"
as the dependency on B could be complex (A || FOO).
Because we would not know if we should enable A or FOO.

So we need some other way to say the C require B.

The suggestion is to introduce a "require" term used
like this:

config A
        bool "a"

config B
        bool "b"
        depends on A

config C
        bool "c"
        require B

The require dependency will have impact on visibility.
C shall only be visible if all symbols it require are
visible. Note that visible does not imply 'chosen'.
In this case C would be visible when A is chosen.

When the user then choose C and B is not chosen 
then the user is prompted to choose B.

So user has to chose B in order to have C chosen.

This would make it visible for the user that choosing
a camera had the side-effect that USB had to be enabled too.
But if we have some general option that prevents the
visibility of USB we would not be offered the camara
in the first place

Comments?

	Sam




             reply	other threads:[~2008-05-04  7:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-04  7:10 Sam Ravnborg [this message]
2008-05-04  8:11 ` kconfig - a suggestion how to fix the select issue 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
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-06  8:19 ` Jan Engelhardt
2008-05-06 15:52   ` Oleg Verych

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=20080504071041.GA15315@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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