> >
> > Also: if there is a driver baz that also requires bar we would want bar
included
> > if EITHER foo or baz were selected, but bar should not be included only
> > if BOTH foo and baz are deslected... Choosing foo should mark bar;
Choosing
> > baz should also mark bar; But if foo is deselected, then bar should not
be
> > unmarked since baz is still selected...
>
> I've actually been thinking about something similar, but before this
morning
> I didn't have a semantics for it that I liked. How about this?
>
> * Implement a stack of "weak" bindings for each symbol, each associated
> with the symbol that forced it. A user setting overrides all weak
bindings,
> otherwise more recent ones have priority over older ones. Whenever a
symbol
> changes value all the weak bindings it forces go away (then it may make
new
> ones). Indicate weak bindings with a distinguished foreground color.
> --
> <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>
There is also something else to consider. Dependant options which are
automatically set. Will they be setup as modules or builtin? If the option
the user chooses is builtin I assume most times the dependancy would have to
builtin also. But if the user chooses a module then whether the dependancy
is a modules also or builtin becomes a question. You may have to pop up a
dialog to ask the user which he perfers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:15 EST