Re: Kconfig bug (was: Re: fault-injection framework on ia64)

[Blaisorblade <blaisorblade@yahoo.it>]

On Friday 16 February 2007 23:26, Roman Zippel wrote:
> Hi,
>
> On Fri, 16 Feb 2007, Blaisorblade wrote:
> > On Friday 16 February 2007 20:12, Roman Zippel wrote:
> > > Hi,
> > >
> > > On Fri, 16 Feb 2007, Blaisorblade wrote:
> > > > However, more important, if I remove STACKTRACE_SUPPORT, or if I make
> > > > it 'default n', FAULT_INJECTION can still be enabled, even if it
> > > > selects STACKTRACE which has a failed dependency (tested on UML).
> > > > Which is a Kconfig bug - if A selects B and B depends on C, no
> > > > dependency of A on C is deduced. Right Roman?
> > >
> > > Correct, but could someone please give me some more context, what the
> > > bug is supposed to be here?
> >
> > Hmm.
> > You agree that "if A selects B and B depends on C, no dependency of A on
> > C is deduced", right?
> >
> > The implication is that the user can enable A, which selects B, while C
> > is still disabled. The B -> C dependency is violated, and the build will
> > fail or bad things will happen.
>
> Indeed, that's why in this case everything that selects STACKTRACE depends
> on STACKTRACE_SUPPORT.

Ah. Ok... so this 'bug' can be workarounded. But couldn't it be fixed or at 
least documented as pitfall? A depends on B is similar, from this point of 
view, to "A selects B", and they could be treated together for recursive 
dependency analisys.
-- 
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com