Re: kconfig - a suggestion how to fix the select issue

Jan Engelhardt
2008-05-06T08:19:14Z

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.