cmake: reducing unnecessary rebuilds

[David Faure]

On Thursday 23 February 2006 15:30, Brad King wrote:
> David Faure wrote:
> > cmake seems to like to rebuild every single object file in kdelibs after I svn update.
> > I'm trying to find out why.
> 
> Can you post two revision numbers such that after building with the 
> first I can update and see this behavior?

I think it was 512488 -> 512700, but it might have been starting from a higher revision
than that. I'll keep an eye on it and tell you if it happens again (it didn't for 512700->512747).

> > One thing I noticed is that DependInfo.cmake seems to be updated just to
> > change the order of lines in it. I guess this is because it comes out of a hashtable?
> > It would need to be sorted, to avoid unnecessary changes (which trigger rebuilding, 
> > or at least unnecessary calls to cmake_depends, right?)
> 
> When a header or source file changes dependencies might have changed so 
> CMake rescans them.  This updates the DependInfo.cmake file, and may 
> write things in a new order.  The order of dependencies listed in the 
> file should not matter.

Of course; I didn't mean that order matters, but that because the file has changed,
its mtime is updated, so more things happen than if the mtime hadn't changed.
This is just a guess based on the assumption that
- the mtime of DependInfo.cmake matters for things that depend on it
- you already have code that avoids touching a file if its contents haven't changed.
But in the 512700->512747 update, the file changed again and nothing got rebuilt
that didn't need to be, so I must be chasing the wrong problem.

> > Also, somehow something deletes many .o files during the build process so I can't
> > see exactly why so many files have to be rebuilt, make -d simply says "kdebug.o
> > doesn't exist anymore, so obviously I need to rebuild it". But why does it get deleted?
> 
> When it is detected that an object file is out of date during dependency 
> scanning it gets deleted to be sure it is rebuilt.  I've forgotten the 
> exact reason we have to do this.  I think we had some problems with low 
> resolution time on make's decision making with some older makes that 
> prevent things from rebuilding unless the object is missing altogether.

:( but that makes debugging with make -d useless. How else can I find out why
an object file is detected to be out of date? Does cmake have a flag for debugging
this, or do I need to add printfs in the code?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).