Roman Zippel wrote:
> On Tue, 29 Aug 2006, Stefan Richter wrote:
[...]
>> The kernel configuration is currently presented as a tree, although the
>> dependencies of config options are not a tree. That's were "select" helps.
>
> Actually dependencies are a tree and kconfig verifies that it's valid as
> well and that's there "select" can wreak havoc.
OK. You are right, they are both trees. But the menu tree is different
from the dependency tree. I can see two reasons: 1. We expect the menu's
layout to reflect function rather than implementation. 2. Menu tree and
dependency tree are directed trees, but only the menu tree has a root
(i.e. _one_ root).
> select really creates a reverse dependency, i.e. the value of SCSI depends
> now on the USB_STORAGE value.
It doesn't really revert the dependency. It changes the path that the
user takes to enable interdependent options. Thereby it changes _how_
the configurator ensures (or rather, _should_ ensure) that dependencies
are fulfilled.
> This means now that all dependencies of the
> selected symbol have to be selected as well (either by the selecting
> symbol or by the selected symbol). With more complex dependencies this can
> quickly get out of hand in order to maintain a valid and correct
> dependency tree. That's why I'm not really happy about the current massive
> use of select and I'd rather find solutions with normal dependencies,
> which unfortunately isn't trivial, select OTOH was a simple hack.
"select" would not be needed if the configurator wouldn't make an option
_invisible_ if it depends on another disabled option. It would be nice
if the option would stay visible (or better yet, would be optionally
visible) and had pointers to unfulfilled dependencies.
Or more generally spoken, "select" would not be needed if there were
other means to switch the configurator's UI to a layout that exposes
more details about dependencies. There is already such a UI mode which
fully exposes _fulfilled_ dependencies.
--
Stefan Richter
-=====-=-==- =--- ====-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]