make KDE4_AUTOMOC compatible to qmake

[Matthias Kretz]

On Monday 18 June 2007, Alexander Neundorf wrote:
> On Saturday 16 June 2007 06:50, you wrote:
> > On Tuesday 12 June 2007, Alexander Neundorf wrote:
> > > Hi,
> > >
> > > On Saturday 09 June 2007 05:20, Matthias Kretz wrote:
> > > > On Saturday 09 June 2007, Alexander Neundorf wrote:
> > > > > On Friday 08 June 2007 05:07, Matthias Kretz wrote:
> > > > > > On Friday 08 June 2007, Alexander Neundorf wrote:
> > > > > > > Using OBJECT_DEPENDS works more or less, but not 100%.
> > > > > > >
> > > > > > :( Is this a bug in cmake or is it some corner case that
> > > > > >
> > > > > > add_library/add_executable works around?
> > > > > >
> > > > > > > IOW we have to stay with a non-source-file extension.
> > > > > >
> > > > > > How about the attached patch? It creates a new top-level target
> > > > > > that depends on all moc custom commands and the
> > > > > > library/executable target then depends on that moc target.
> > > > > > I tried it with a clean kdelibs build and it created _all_ moc
> > > > > > files before it started any compile job. I'm not sure why
> > > > > > cmake/make does that but it's not really wrong either.
> > > > > >
> > > > > > A variation of the patch could be to check for .cpp files in
> > > > > > _automoc_FILES and only then add this additional top-level
> > > > > > target. Else do the same as before.
> > > > >
> > > > > I still have a patch here which moves the automoc test from
> > > > > cmake-time to build time (i.e. faster cmake run)
> > > > > This and your patch might fit together.
> > > > > I have to get it up-to-date and then we can see whether they work
> > > > > together. Please don't commit before.
> > > >
> > > > OK, then I'll revert my local moc include changes in phonon -
> > > > otherwise I can't work on it anymore... The reason why I'd like to
> > > > have it working soon is that Trolltech wants to be able to compile
> > > > phonon using qmake (makes it easier for them to work on Windows and
> > > > MacOS).
> > >
> > > attached you can find a modified KDE4Macros.cmake.
> > > It creates for every target a automoc target, which executes an
> > > external cmake script (kde4automoc.cmake), which does the actual
> > > parsing. It seems to work here for me for kdelibs.
> > >
> > > In kde4automoc.cmake it should be easy to also search for moc_*.cpp
> > > files.
> >
> > Yep. That was easy. :-) Patch attached.
> >
> > > Please give it a try and see how it works.
> >
> > So far it's been working great. I especially like that I don't have to
>
> Good to hear :-)
> So you didn't have any problems ?

I hit a problem yesterday in kdebase. There a kcfgc file was compiled into 
prefs.cpp. The target that was using the prefs.cpp file with the config 
compiler cmake macro build fine, but there was another target that simply 
specified prefs.cpp for its sources. I changed it to 
${CMAKE_CURRENT_BINARY_DIR}/prefs.cpp and then it worked. Apparently this 
worked with the old automoc, but I'm not sure why...

> > rerun cmake when something automoc related changes and the CMakeLists.txt
> > files don't change (e.g. if you forgot to #include the moc file). There
> > are many STATUS messages, but I guess you'll comment those out before
> > committing to trunk?
>
> I can do that.
> I thought it would be nice if you see what's going on, but it#s probably a
> bit much.

Perhaps the "generating" message could be kept.



-- 
________________________________________________________
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: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20070618/3eda608a/attachment.pgp