On Mon, May 25, 2015 at 07:07:14PM +0000, James Bottomley wrote: > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote: > > On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote: > > > On Fri, 2015-05-22 at 14:43 -0700, j...@joshtriplett.org wrote: > > > > Ideally, someone should teach Kconfig to handle recursive dependencies, > > > > > > I'm probably reading too much in this remark, but how should it handle > > > that other than returning an error because the configuration it's fed > > > makes it run in circles? > > > > I don't mean cyclic dependencies (for which Kconfig should just report > > an error, ideally including the full list of symbols forming the cycle). > > > > I mean that Kconfig should do recursive dependency resolution. If B > > depends on A, and C depends on B, I should be able to turn on C > > directly and have B and A enabled. > > That's really hard in practise you have to make any symbol that selects > something depend on the dependencies of the selected symbol. You can't > do this without involving a SAT solver. A guy promised to do this a > couple of years ago, but the patches never materialised. However, they > may exist somewhere if someone wants to take a look at completing it.
You can't do this in the completely general case without a SAT solver. However, I think it's possible to help the user a bit more than than Kconfig currently does without introducing a general dependency solver. In particular, it'd be nice to have an easy way to see at a glance "can't enable C because it depends on B", together with an easy way to get to B to enable it to get to C. User-guided dependency resolution seems like an improvement over no dependency resolution. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
