On Wed, 2009-08-12 at 14:36 +0200, Arnd Bergmann wrote: > On Wednesday 12 August 2009, Catalin Marinas wrote: > > The "select" statement in Kconfig files allows the enabling of options > > even if they have unmet direct dependencies (i.e. "depends on" expands > > to "no"). Currently, the "depends on" clauses are used in calculating > > the visibility but they do not affect the reverse dependencies in any > > way. > > > > The patch introduces additional tracking of the "depends on" statements > > and does not allow selecting an option if its direct dependencies are > > not met, also printing a warning. > > > > Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx> > > Cc: Sam Ravnborg <sam@xxxxxxxxxxxx> > > I guess this will change the behaviour of a number of subsystems, > likely causing unexpected regressions. I think your change > makes sense, but we need to be much more careful. It would indeed cause regressions, that's why I'm only asking for comments currently. > Can you extract a list of configuration symbols that are > impacted by your patch? I can generate a list with allyesconfig but it looks like it breaks some common usage in Linux. For example, the VIDEO_* entries in drivers/media/video/Kconfig under the "Encoders/decoders and other helper chips" menu automatically inherit a dependency on !VIDEO_HELPER_CHIPS_AUTO. This option is enabled to allow other config options to select whatever they need. But it would fail with my patch because of the direct dependency of the VIDEO_* options on !VIDEO_HELPER_CHIPS_AUTO. It needs a bit more thinking here and maybe writing something like: menu "..." if !VIDEO_HELPER_CHIPS_AUTO rather than menu "..." depends on !VIDEO_HELPER_CHIPS_AUTO though the parser (after modifying the zconf.y to handle this) seems to consider both dependencies at the same level -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
