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

    "A month of sundays ago Paul Flinders wrote:"
    > > From: Peter T. Breuer <>
    > > 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).

    > 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

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


    > 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


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

     \ /
      Last update: 2005-03-22 13:38    [W:0.025 / U:24.460 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site