On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote:
> I think part of the problem is that "select" is often used not as
> documented [1] but rather as "show my config in menuconfig for
> convenience even if my dependency is not met, and select the dependency
> even though I know it can screw up the dependency chain".
Perhaps people use select because it offers, given the problem they
face, a reasonable way to make the kconfig tools generate a
sensible .config. It helps them to spend less time fiddling with Kconfig
files. And they expect that it helps others to configure their build
more easily, as it might save those others some work.
> In the big picture, it feels like menuconfig needs a way to display
> items whose dependencies are not met, and a way to recursively enable
> said items and all their dependencies when told.
How could that work its way through (multiple levels of) things like:
depends on FOO || (BAZ && BAR)
> This would reduce the
> resistance to sticking with "select" when clearly "depends" is what's
> meant.
I had drafted a rather verbose response to this. But I think I'm not
really sure what you're saying here, probably because "select" and
"depends on" are rather different. How would you know that the actual
intention was to use "depends on"?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
