mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Alistair John Strachan <alistair@devzero.co.uk>,
	Robin Holt <holt@sgi.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.26-rc1
Date: Thu, 08 May 2008 16:11:53 +0200	[thread overview]
Message-ID: <48230A29.9020008@s5r6.in-berlin.de> (raw)
In-Reply-To: <20080508094820.33ea42f4@gaivota>

Mauro Carvalho Chehab wrote:
> In the case of those tuners, all have the same dependencies:
> DVB or V4L and I2C. That's the reason why I've removed the
> individual dependencies.

Which I just wrote is dangerous.  It is easy to get wrong, and it is not
maintainable.

Here is what I would do:

config TUNER_1
	tristate "Tuner 1"
	depends on ACTUAL_DEP1_OF_T1 && ACTUAL_DEP2_OF_T1

config TUNER_2
	tristate "Tuner 2"
	depends on ACTUAL_DEP1_OF_T2 && ACTUAL_DEP2_OF_T2
	select ACTUAL_DEP3_OF_T2

In this example, ACTUAL_DEP3_OF_T2 does not have further dependencies
itself.

And if you believe that Kconfig should assist with runtime dependencies
too, not just build-time dependencies, and you believe that the "help"
and "comment" directives are insufficient for that, then add
meta-options like this:

config META_TUNER_A
	tristate "Meta-tuner A"
	select TUNER_1
	depends on ACTUAL_DEP1_OF_T1 && ACTUAL_DEP2_OF_T1  # for TUNER_1
	select TUNER_2
	depends on ACTUAL_DEP1_OF_T2 && ACTUAL_DEP2_OF_T2  # for TUNER_2
	select ACTUAL_DEP3_OF_T2                           # for TUNER_2
	help
	  Adds support for cards which contain tuner 1 and/or tuner 2.

So, like I said before, I recommend:

  - If an option has an actual build requirement, state it explicitly
    by "depends on" (or alternatively "select") directly at this option.

    Alternatively, enclose this option or a block of options which
    have identical dependencies in an "if"/ "endif" block, conditional
    on this common dependency.

  - Whenever you use "select", *copy* all dependencies of option A to
    option B if B selects A.

    Alternatively, replace "select" by "select ... if C" and *copy*
    all dependencies of option A to option C.

This is because the Kconfig files (1.) must correctly state all build
dependencies and (2.) must be maintainable.

If you "select" a lot, you will have of course a lot of dependencies to
copy.  That's the nature of "select".  You can't get around that.  Not
as long as there is no "select" which recursively checks and maybe
selects dependencies of dependencies.
-- 
Stefan Richter
-=====-==--- -=-= -=---
http://arcgraph.de/sr/

  reply	other threads:[~2008-05-08 14:13 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8287f540805041818g534c4e02qaadb0e749c5f3439@mail.gmail.com>
2008-05-03 19:38 ` Linus Torvalds
2008-05-03 21:47   ` Alistair John Strachan
2008-05-03 21:53     ` Alistair John Strachan
2008-05-04 12:30       ` Robin Holt
2008-05-04 13:56         ` Alistair John Strachan
2008-05-04 16:09           ` Robin Holt
2008-05-04 16:33             ` Alistair John Strachan
2008-05-05 21:04             ` Mauro Carvalho Chehab
2008-05-06  8:02               ` Alistair John Strachan
2008-05-06 10:31                 ` Mauro Carvalho Chehab
2008-05-06 14:34                   ` Stefan Richter
2008-05-06 14:54                     ` Stefan Richter
2008-05-06 19:13                     ` Mauro Carvalho Chehab
2008-05-06 19:44                       ` Stefan Richter
2008-05-06 20:06                         ` Mauro Carvalho Chehab
2008-05-06 20:47                           ` Stefan Richter
2008-05-06 22:39                             ` Mauro Carvalho Chehab
2008-05-06 23:36                               ` Stefan Richter
2008-05-08 12:48                                 ` Mauro Carvalho Chehab
2008-05-08 14:11                                   ` Stefan Richter [this message]
2008-05-06 23:48                             ` Stefan Richter
2008-05-04  7:29   ` [patch] sysfs: build fix Ingo Molnar
2008-05-04 18:40   ` Linux 2.6.26-rc1 Jan Engelhardt
2008-05-05  5:39   ` Andreas Mohr
2008-05-05  7:30     ` Ingo Molnar
2008-05-05 20:14       ` Mauro Carvalho Chehab
2008-05-06 13:07         ` Ingo Molnar
2008-05-07  8:35           ` Ingo Molnar
2008-05-05 23:51       ` Stephen Rothwell
2008-05-05 23:55         ` David Miller
2008-05-06  0:16           ` Andrew Morton
2008-05-06  5:57             ` Stephen Rothwell
2008-05-06  0:21           ` Ingo Molnar
2008-05-06  5:35           ` Stephen Rothwell
2008-05-06  6:56             ` David Miller
2008-05-06  7:26               ` Stephen Rothwell
2008-05-06  0:17         ` Ingo Molnar
2008-05-06  5:48           ` Stephen Rothwell
2008-05-06  6:07   ` Scheduling problems ? [ Was: Linux 2.6.26-rc1 ] J.A. Magallón
2008-05-06 13:11     ` Ingo Molnar

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=48230A29.9020008@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=alistair@devzero.co.uk \
    --cc=holt@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=torvalds@linux-foundation.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®