On Sunday 2008-05-04 09:10, Sam Ravnborg wrote: >Today we have two ways to express/solve dependencies. > >Top-down we have "depends on" >and bottom up we have "select". > >The "depends on" dependencies at the same time impact the visibility of >a symbol. A symbol with "depends on" not satisfied are not visible and >thus not shown in menuconfig. > >The "select" method is a way to forcefully set the selected symbol to >the same value as the one where the select are stated. > >But this has shortcoming in relation to the interface we like to >present to the user. [...] Suggestion: Make kconfig work like an interactive package manager. All objects are visible and the user can select any of them. depends and selects are resolved upon request only, i.e. when the user hits Exit or manually initiates a resolve request. Kconfig then checks to see if all dependencies are satisfied, and if it cannot automatically solve it — because it encounters an alternation expression (a || foo) — it asks the user to select one. If user input is not available, exit with error (much like `make oldconfig </dev/null` already does on new options.) Drawback: Most likely a lot of work. Consider/Suggested syntax: menuconfig V4L2 tristate "video and all that" if V4L2 config MY_CAMERA tristate "nice cam" requires USB || FIREWIRE endif leading to a new screen on dependency resolution (when USB=n && FIREWIRE=n), showing a modified "choice" prompt where you can either 1) change the state of CONFIG_MY_CAMERA to y/m/n. 2) select one of the required dependencies. CONFIG_MY_CAMERA has unsatisfied dependencies. <M> nice cam ( ) USB ( ) FireWire Of course a bit of thinking on how to display things is needed for more complex requires. -- 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
