mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: "Robert P. J. Day" <rpjday@mindspring.com>,
	jidong xiao <jidong.xiao@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: what does select statement mean in Kconfig file?
Date: Sun, 22 Jul 2007 00:00:55 +0200	[thread overview]
Message-ID: <46A28217.2060005@s5r6.in-berlin.de> (raw)
In-Reply-To: <m3lkd95tzf.fsf@maximus.localdomain>

Krzysztof Halasa wrote:
> Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
> 
>> The latter is sometimes hard or impossible to satisfy.  Therefore the
>> select statement should be used with care, i.e. only for library-type
>> helper code which itself shouldn't depend on further options.
> 
> How about depending on common dependency?
> 
> Something like
> 
> config A
> 	bool XXX
> 	depends on ARM
> 
> config B
> 	depends on ARM
> 	select A
> 
> 
> or:
> 
> if ARM
> 	config A
> 		bool XXX
> endif
> 
> if ARM
> 	config B
> 		select A
> endif

That's OK.  Or generally, if A depends on X and B wants to select A,
then it has to be guaranteed by whatever means that X is enabled,
because "make XYZconfig" cannot select recursively.  Duplicating A's
dependencies as dependencies for B is one way to ensure that A's
dependencies are satisfied when B selects A.  Another way is to select
not only A but also A's dependencies.

That's why I wrote "/shouldn't/ depend on further options" rather than
"/must not/ depend on further options".

But whatever you do, as soon as you add a "select A", you have to watch
if anybody eventually makes A dependent on something else.  Therefore
think twice before you use select.

Also, while select makes it easy for users to enable options, it makes
it somewhat difficult for users to /disable/ options.  So there are also
tradeoffs in usability.  This essentially means that you should never
select huge subsystems.  As I said, only library-like helpers are
suitable for select.
-- 
Stefan Richter
-=====-=-=== -=== =-=-=
http://arcgraph.de/sr/

      reply	other threads:[~2007-07-21 22:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-21 13:34 jidong xiao
2007-07-21 13:38 ` Robert P. J. Day
2007-07-21 16:51   ` Stefan Richter
2007-07-21 21:26     ` Krzysztof Halasa
2007-07-21 22:00       ` Stefan Richter [this message]

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=46A28217.2060005@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=jidong.xiao@gmail.com \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpjday@mindspring.com \
    /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®