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/
