OK - I used a very very fast machine to get that figure (and fast scsi
drives - and 96M of ram).
> Not a major pain as the kernel takes a while to compile on this machine
> anyway but I believe (after a quick perusal of the .depend files) that
> mkdep
> is fast mainly because it skips stuff.
Absolutely wrong (i.e. "that turns out not to be the case" :). It is
fast per se and it is helped to be fast by the factthat it does not skip
stuff that a cleverer but slower implementation might be able to skip.
(gcc is such a beast). It produces a conservative overestimate of the
semantically exact dependencies. It is purely a syntactic dependency
chaser!
> > 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. Call the time to recompile the dependencies as it goes X.
> > Call the time to recompile the object code Y. So the total is X + Y.
>
> 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.
>
> Can you suggest a concrete example of when you would touch a file
> which you don't want to be re-compiled.
see above. Pick any file not in my architecture.
> >
> > 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
> >
> > This cannot be worse that X+Y!! You would only have a chance of winning
> > out if I had to recompile 80% of my files after an upgrade, which is
> > not the case.
> >
> > In any case, what really happens is that I run mkdep, which takes 0s
> > effectively, and then get a slightly worse approximation to the files
> > taht I need to recompile. Say I have to recompile 60% instead of 50%.
> > Then the total time used is
> > 0 + 0.6*Y = 0.6*Y
>
> The amout of extra time taken by -MD is *very* small. I don't see why
I know. I called it X.
I only assume that it is positive. It could be 0.0001*Y as far as I
am concerned and the above shows that it is still too large! You can't
beat the math. My point was that 0.7*Y NOT GREATER THAN Y + X.
> 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
> Using -MD kives you an accurate picture of the dependancies which
> is always up-to-date. mkdep appears to give a partial picture (it doesn't
> on brief examination appear to output dependancies for nested files).
That is incorrect.- unless there is a real bug in the mkdep code!
> the dependancies generated by mkdep can also become out of date
> (as soon as you add a new header to a source file)
Of course, so what?
> mkdep also ignores #if/#endif which means that I might end up
> re-compiling a file un-necessarily because I edit a header which a
> source file includes in *some* circumstances but not in the current
> configuration.
Yes - that is what I said. It is a conservative (i.e. "safe") over
estimate of the semantic dependencies.
>
> 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.
> b) I can forget to do it.
> 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 think that using -MD would eliminate the non-module part of a) and
Se separate argument about why not in private email.
> eliminate b). It shouldn't affect the "robustness" of the dependancy
True
> tracking (in fact it will probably improve it).
There is no problem with the dependency tracking unless there is a bug.
The mkdep dependencies are already over-robust.
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.
---------------------------------------------------------------------
Peter T. Breuer Phd. Ing.,
Area de Ingenieria Telematica E-mail: ptb@it.uc3m.es
Dpto. Ingenieria Tel: +34 1 624 99 47
Universidad Carlos III de Madrid Fax: +34 1 624 94 30/65
Butarque 15, E-28911 Leganes URL: http://www.it.uc3m.es/~ptb
Spain