[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).
    "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 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

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


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