Re: State of the new config & build system

[Mike Touloumtzis]

On Fri, Dec 28, 2001 at 12:57:58PM +1100, Keith Owens wrote:
> 
> Unlike the broken make dep, kbuild 2.5 extracts accurate dependencies
> by using the -MD option of cpp and post processing the cpp list.  The
> post processing code is slow because the current design requires every
> compile to read a complete list of all the files, giving O(n^2)
> effects.  Mark 2 of the core code will use a shared database with
> concurrent update so post processing is limited to looking up just the
> required files, instead of reading the complete list every time.

Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the dependencies
as a side effect of the regular compile step?  This enables you to skip
the initial dependency preprocessing step entirely, and could lead to a
speedup over even the current fastdep system.  You still have to massage
the dependencies but you can do it based on the side-effect dependency
output of the _previous_ build, to whatever degree that output exists.

This strategy allows for lazy dependency generation in those cases in
which the dependencies need not be known--for example, if floppy.o
doesn't exist, you know it needs to be built no matter which header
files floppy.c may include.  This breaks down in some cases (as when a
.c file depends on a generated .h file) but those breakdown cases can
be explicitly identified, and a full dependency tree be generated for
them in an eager, rather than a lazy, fashion.

It seems like it's worth it if it leads to a near 100% speedup over the
current kbuild 2.5.  The "build whole clean tree" case is a common one
even among kernel developers, e.g. for compile-testing patches before
resending them.

miket