Re: kbuild: fixing the select problem

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2010-05-06 at 08:47 +0200, Geert Uytterhoeven wrote:
> On Wed, May 5, 2010 at 23:49, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > [Sam: I know you don't maintain kbuild anymore, but since you have the
> > most experience, if you could find time to comment, I'd be grateful]
> >
> > The select problem is that the kbuild select directive will turn a
> > symbol on without reference to its dependencies.  This, in turn, means
> > that either selected symbols must select their dependencies, or that
> > people using select have to be aware of the selected symbol's dependency
> > and build those dependencies into their symbol (leading to duplication
> > and the possibility of getting the dependencies out of sync).  We use
> > select for the scsi transport classes, so we run into this problem in
> > SCSI quite a lot.
> >
> > I think the correct fix is to make a symbol that selects another symbol
> > automatically inherit all of the selected symbol's dependencies.
> 
> What if there's a good reason the selected symbol has this dependency?
> E.g. it depends on a critical feature not available? Like CONFIG_HAS_IOMEM?

I don't quite understand the question.  If a selected symbol has a
critical dependency which is config'd to N then the build usually
breaks ... that's what I'm calling the select problem.  I thought
CONFIG_HAS_IOMEM was usually selected by the architecture, though.  In
the new proposal, we wouldn't be able to generate the invalid
configuration in the first place.

James