lkml.org 
[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch, -git] media/video/sound build fix, TEA5761/TEA5767

* Sam Ravnborg <sam@ravnborg.org> wrote:

> [OT to the actual problem]
>
> I have envisioned something like a "requires tag" that would list what
> a config symbols needs.
>
> Like in this case it would have been:
>
> requires V4L
>
> This should in the frontends then if the user selects a symbol where
> the 'requires' are not satisfied with a window listing the menuentries
> for the symbol that the user needs to enable to satisfy what the
> original symbol requires.
>
> This is the only way to do this in a way so the user is actually aware
> that enabling a webcam also enables USB. Or at least this is my best
> suggestion.

but auto-selecting USB is the obvious thing that most users expect...

I.e. they expect a static hierarchy of 'every component' that exists and
that can be selected. [yes there are complications like multiple-choice,
but that's the minority]

Users want to browse the hierarchy and pick their things - and _at most_
the tool should warn if there's side side-effects of a selection - users
will likely not mind that enabling a webcam also enables USB (in the
overwhelming majority of the cases they couldnt care less about that).

But otherwise it should all be automatic.

And i dont even think there should be any additional Kconfig
complication. Kconfig should be made _simpler_, not more complex.
Maintainers list dependencies and that's it. No "select" needed at all!
The stuff that needs to be selected automatically derives from the
"depends on" tree that we code.

in fact even dependencies between modules of source code should be
auto-discovered most of the time.

The symbol dependency tree from an allyesconfig kernel could give a 99%
accurate map of all the dependencies that exist in the code. Why burden
humans with that? We've got better things to do than to figure out
dependencies between source code as the dependencies can be totally
non-obvious.

Humans might want to _optimize_ the dependencies after the fact and get
rid of unnecessary dependencies (so that the kernel gets smaller, etc.),
but there should be no correctness ramifications of it visible to
developers or users.

So the whole thing is being thought about exactly upside down i believe.

Ingo


\
 
 \ /
  Last update: 2008-04-30 14:23    [from the cache]
©2003-2011 Jasper Spaans