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. -- ________________________________________________________ Matthias Kretz (Germany) <>< http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
