lkml.org 
[lkml]   [1996]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: source dependencies cleanup?
Date

> "A month of sundays ago Paul Flinders wrote:"
> > > From: Peter T. Breuer <ptb@oboe.it.uc3m.es>
> > > a) it isn't 8 seconds worth of fast, which is the mkdep time.
> > On a 66 Mhz 486 at work "make depend" takes just under 3 minutes.
> OK - I used a very very fast machine to get that figure (and fast scsi
> drives - and 96M of ram).
"make depend" is going to be a separate pass over the files, no matter what.
Unless you have the excessive gobs of RAM to cache the whole source tree
in RAM, -MD (or -MMD, if we want to only list "included", not <included>
files) ought to save time for most people if used right. The question
is, is it worth the time to change do it and use it right?

> > > b) it requires you to recompile every touched file every time you make
> > > any update to your system, even if you don't want those files to be
> > > compiled.
Why? If the target depends on the set of files D, and the set of files
touched is T, then only D intersect T needs to be looked at anyway. So
long as the *.a: *.o dependencies can be figured out by the configuration
script, no problems at all... Who cares what files in T that we don't
depend on include?

> > Without doing a lot of work at a sub-file granularity I would be reluctant
> > *not* to re-compile a file which had been touched as part of an update.
> That's wrong. Linus updates the alpha stuff practically every release,
> and I am not going to recompile _that_! Then there is the m68k stuff,
> the scsi stuff on a non-scsi machine, all the net drivers that I don't
> need (I only have one type of card and I use it as a versioned module)
> plus the sound that I don't use, all the isdn stuff, all the file systems
> that I don't use etc. etc. etc.
See above. If we get the right .a and .o files depended on, the above
shouldn't matter.

> > > c) because of b) (and a)!), it is a lot slower than a makedep follwed
> > > by a conditional recompilation. Suppose the makedep takes an extra
> > > 20% of Y, but that after the makedep I only have to actually recompile
> > > 50% of my files. Then the time to recompile is
> > > 0.2*Y + 0.5*Y = 0.7*Y
If you're doing things right, then gcc (-MD) will only be run on the changed
files on which the current configuration depends...so it's 0.2Y+0.5Y vs.
(0.5+e)Y, and we're back to the question 0.2<?e.

> > any files would be re-compiled without needing to be modulo that fact
> > that the current scheme may avoid placing commonly changed files
> > (eg autoconf.h) in the dependancies because most of the kernel includes
> > them and any edit causes the whole kernel to be re-compiled. However IMO
> > it is dangerous to omit dependancy information like this and the correct
> > fix is to split the config #defines into several files.
> The last is correct
I really do think the config #defines ought to be split out; either I'm
just doing a rebuild after an update and don't trust the dependencies (and
thus do a make clean), or I'm doing a lot of compiles in which case I'm
doing make menuconfig a heck of a lot... Plus every so often new options
show up or change (witness the recent IDE config revamp) so I tend to do
a make menuconfig just to make sure everything's as it should be.

> > In my experience
> > a) "make depend" is still a noticable addition to the compilation time
> > (although some of this is to do with modules which may still need
> > to be done & making sure that happens appropriately will need
> > though)
> Use versions.
That only answers the modules half... the other half you apparently took
offline...

> > b) I can forget to do it.
This is a big point; I've gotten into the habit of "make {dep|clean} zlilo
modules modules_install", but... Besides, "make dep" ought to just update
the dependencies for the current configuration anyway...

> > c) When I really want it to re-compile a small subset of files
> > after a config change I get half of the kernel re-compiled anyway.
> True.
I second (third?) this; I'd almost prefer dependency rules that say "this
needs rebuilding if any of X files change, or if any of Y->Z config setups
change" if we've got to have a separate pass.

> I am afraid you cannot beat the math above. You may wish to suggest
> alternative figures? Your method should produce at least a 30%
> slowdown according to what I suggested as reasonable. I tried to err on
> your side - though maybe 0.7 should be 0.75.
Again, see above. If we don't need foo.o, then we don't need to even find
dependencies for foo.[cs]...

Keith

\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site