Krzysztof Halasa wrote:
> Stefan Richter <[email protected]> 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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
