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/
--
