make KDE4_AUTOMOC compatible to qmake
Matthias Kretz
kretz at kde.org
Sun Jul 1 22:19:58 CEST 2007
On Friday 29 June 2007, Alexander Neundorf wrote:
> On Thursday 28 June 2007 11:20, Matthias Kretz wrote:
> > after that it seems to work, at least my stuff. Here's an error I didn't
> > look into:
> > Scanning dependencies of target globalcleanuptest
> > [ 8%] Building CXX object
> > kdecore/tests/CMakeFiles/globalcleanuptest.dir/globalcleanuptest.o
> > g++: libs/kdecore/tests": No such file or directory
> > <command line>:1:1: warning: "KDESRCDIR" redefined
> > <command line>:1:1: warning: this is the location of the previous
> > definition make[2]: ***
> > [kdecore/tests/CMakeFiles/globalcleanuptest.dir/globalcleanuptest.o]
> > Error 1 make[1]: *** [kdecore/tests/CMakeFiles/globalcleanuptest.dir/all]
> > Error 2
> >
> > I renamed my src/kdelibs dir to src/kde\ libs and obj/kdelibs to obj/kde\
> > libs
>
> make VERBOSE=1 would be help more here.
Yes, in the meantime I fixed it in trunk already.
> > Last night it occurred to me that adding a custom target is very IO
> > expensive since it needs to create the whole ${target_name}.dir directory
> > structure plus all the files contained in it. So I tried to get rid of
> > the custom automoc target again and instead use a custom command. Patch
> > against trunk (svn di -x -w) attached.
>
> So instead of creating a target you create a custom command which produces
> the mark file which is added as source to the target which will not be
> compiled because it has an unknown suffix.
> Sounds good at a first glance.
Exactly. And I made the mark file depend on all relevant .cpp files and
their .h counterparts if they exist. That way touching the .h file will run
the automoc.
> > timings for kdelibs with the new patch:
> > without cache: 37.97s user 10.99s system 45% cpu 1:46.53 total
> > with cache: 14.89s user 2.13s system 24% cpu 1:09.05 total
> > CPU usage seems higher, it still seems faster though which must be from
> > the reduced IO.
>
> So this saves 1 to 2 from 39 s ?
> Can you reproduce this or can this also be random noise ?
It is reproduceably faster than the older automoc patches.
Compared to current trunk it's still slower (my timing above must've been a
lucky run):
trunk : total time = 1:11.50s +/- 2.33s (10 runs)
patched: total time = 1:19.02s +/- 5.82s (19 runs)
Also, looking at the speed of the kde4automoc script is not very
convincing. :-( I think the potential of this change is to make the automoc
pick up changes without having to rerun cmake, but not to increase the speed.
Regarding "picking up changes" I had another idea: The .automoc file could be
used to #include all the moc files that are not #included in any .cpp file of
the target. Then the target would "compile and link that file". That way the
automoc, that is run at make time, can dynamically add and remove files
to/from the target.
As a developer you'd simply add a Q_OBJECT macro to a .h file and magically
the moc would be run, compiled and linked in without having to change
CMakeLists.txt and without having to rerun cmake.
--
________________________________________________________
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/20070701/df455082/attachment.pgp
More information about the Kde-buildsystem
mailing list