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 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
