CMake dependency scanning for .moc files

[Matthias Kretz]

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/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20080416/aece0d26/attachment.pgp