lkml.org 
[lkml]   [2001]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: State of the new config & build system
Date
On Fri, 28 Dec 2001 04:26:48 -0500, 
Legacy Fishtank <garzik@havoc.gtf.org> wrote:
>On Fri, Dec 28, 2001 at 01:54:42AM +0100, Dave Jones wrote:
>> How far down the list was "make it not take twice as long
>> to build the kernel as kbuild 2.4" ? Keith mentioned O(n^2)
>> effects due to each compile operation needing to reload
>> the dependancies etc.
>
>Each compile needs to reload deps???
>
>Ug. IMHO if you are doing to shake up the entire build system, you
>should Do It Right(tm) and build a -complete- dependency graph -once-.

We have one complete dependency graph for the explicit dependencies.
What is slow is extracting the implicit dependencies after an object
has been compiled, i.e. the files that it includes. Actually
extracting the implicit dependencies is fast, converting them to
standard names is fast, what is slow is _reading_ the big list that
maps from absolute names to standardized names.

I need the big list in order to remove absolute names in the dependency
trees. kbuild 2.4 forces a complete recompile if you rename a tree,
including if you build on one system then try to install via NFS on a
second system. kbuild 2.5 can cope with trees being renamed and trees
having different names on local and NFS mounted systems. That
flexibility comes at a cost.

"All" I need to do is have one server process that reads the big list
once and the other client processes talk to the server. Much less data
involved means faster conversion from absolute to standardized names.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:18    [W:0.267 / U:8.988 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site