On Friday 22 February 2008, Brad King wrote:
> David Faure wrote:
> > CMakeFiles/kdecore.dir/depend.make is empty ("# Empty dependencies files, #
> > This may be replaced when dependencies are built")
> > CXX.includecache is up at http://web.davidfaure.fr/tmp/CXX.includecache
> > (strange syntax, is the "target" the first line after an empty line?)
>
> Ask Alex, he wrote the include cache stuff, and it does make dependency
> scanning amazingly fast. I think the syntax is meant to be very fast to
> parse.
Sure, thought so.
> >> Can you reproduce it in a new build tree?
> > OK, that was it.
> > I deleted the kdecore build dir and ran cmake again, and now it works as
> > expected.
> [snip]
> > Maybe cmake could do like Qt's moc and say "this build tree was generated
> > with cmake-2.4, you need to delete it and regenerate it to use this version
> > of cmake" or something like that?
>
> Well, the intention is to work with existing build trees. I just tried
> generating a simple example project with 2.4 and then running CMake from
> CVS on it. Everything still rebuilds correctly (both with and without
> building between the cmake runs). Are you able to reproduce this if you
> create a kdecore tree with cmake 2.4 and then run cmake HEAD on it again?
Hmm, I tried with kdetoys (for a smaller testcase) and it worked fine there.
However I realized now that my kdelibs problem wasn't a 2.4 -> 2.5-20080221
upgrade,
but a 2.5-20071005 -> 2.5-20080221 upgrade, which might be different.
Maybe not worth spending more time on it then...
PS: One thing I noticed: I still have -DCMAKE_SKIP_RULE_DEPENDENCY=TRUE enabled
(both with 2.4 and 2.5-cvs), but from the notes I kept about it it should be
unrelated (I did my tests with it)
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
Kde-buildsystem mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-buildsystem
