Messages in this thread |  | | From | Keith Rohrer <> | Subject | Re: source dependencies cleanup? | Date | Tue, 3 Dec 1996 18:31:29 -0600 (CST) |
| |
> "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
|  |