On Wednesday 16 April 2008, Matthias Kretz wrote: > On Wednesday 16 April 2008, Alexander Neundorf wrote: > > On Wednesday 16 April 2008, Andreas Pakulat wrote: > > > On 15.04.08 19:19:45, Alexander Neundorf wrote: > > > > On Monday 14 April 2008, Andreas Pakulat wrote: > > > > > Hi, > > > > > > > > > > so today I found that there are actually problems with cmake 2.6 > > > > > and dependency scanning. > > > > > > > > > > a) after changing an installed header the .moc files for headers > > > > > that include the updated header are not re-generated which might > > > > > cause problems when you do ABI changes (like removing a method) on > > > > > the installed header (linking errors) > > > > > > > > > > b) removing a .moc file from the builddir doesn't produce a re-moc, > > > > > cmake just tells gcc to compile the non-existing .moc-file. > > > > > > > > > > I'm actually not sure wether either of the two ever worked, but > > > > > IMHO at least the second one should work. > > > > > > > > > > This is was tested on CMake 2.6 and 2.4.7. > > > > > > > > And it works with 2.4.7 but doesn't with 2.6 ? > > > > > > It doesn't work with either of the two. > > > > Ok, so it's at least no cmake 2.6 problem, but automoc. > > > > > > This is a moc file handled via automoc, right ? > > > > > > Yes. The only way to get cmake to re-generate the .moc file is to touch > > > the header from which its generated or remove the subdir in the > > > builddir that contains the .moc file. > > In the resulting Makefiles there are no dependencies on the actual moc > files. The upside of this is that changing a moc-include doesn't need a > cmake rerun (that includes adding Q_OBJECT to a class - before kde4automoc > you had to rerun cmake then). Even if the Makefile doesn't have a dep on > the moc files, if kde4automoc is run it will compare the timestamps of the > moc file against it's source file (header or cpp), that's why touching the > .h file works. > > IIUC you want to look at the timestamps of all the headers that are > directly or indirectly included from the file that is moced. AFAIK not even > cmake generated Makefiles do that for compilation (I imagine that would be > rather expensive information). If they do I'd like to know how to get at > that dependency info to reuse it for kde4automoc. > > But really, I think that if the installed headers change in a binary > incompatible way the only safe thing you can do is a make clean. > > Conclusion: I think everything works as it should. At least from the > problem description above.
For case a) I agree, but what about the deleted moc file in case b) ? Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
