On Wed, Apr 30, 2008 at 02:18:54PM +0200, Ingo Molnar wrote:
quoted text
> 
> * 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).

Which is exactly what my "require SYMBOL2 would give us.
A webcam would not depends on USB, but would "require USB".
If the decide to include the webcam she will optionally be prompted
so she can decide if it is OK to include USB support too.

But again - have not thought this to the end.

quoted text
> 
> 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.
Would be nice.

	Sam
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/