make KDE4_AUTOMOC compatible to qmake

[Alexander Neundorf]

On Thursday 28 June 2007 11:20, Matthias Kretz wrote:
> Alex wrote:
> > On Wednesday 27 June 2007 18:26, Matthias Kretz wrote:
> > > old automoc:
> > > without cache: 39.47s user 12.53s system 36% cpu 2:22.32 total
> > > with    cache: 16.59s user  2.62s system 26% cpu 1:13.69 total
> > >
> > > new automoc as from Alex's patch:
> > > without cache: 38.78s user 12.06s system 32% cpu 2:38.27 total
> > > with    cache: 16.15s user  3.01s system 18% cpu 1:42.67 total
> > >
> > > reworked patch:
> > > without cache: 39.01s user 11.80s system 34% cpu 2:26.86 total
> > > with    cache: 16.03s user  2.75s system 20% cpu 1:32.07 total
> > >
> > > without cache means:
> > > % rm CMakeCache.txt
> > > % time cmake -DCMAK... ../../src/kdelibs
> >
> > I didn't mean the cmake cache, I meant the disk cache, i.e. compared
> > directly after booting (with cold cache) and when running cmake multiple
> > times in a row (-> warm caches).
>
> That's what I feared you'd mean. And no, I won't really test that except if
> you give me a method to clear the disk cache without rebooting and without
> waiting forever.

Same here.
I can vaguely remember that I once read about how to do this. Like doing 
something different very IO intensive in between. But I can't remember 
exactly what it was. My attempts at emptying the cache failed.

> > > Anyway, I changed quite a bit:
> > > 1. don't create _automoc.files files anymore; instead pass all the
> > > variables on the command line to kde4automoc.cmake. I did this in order
> > > to
> >
> > The thing to watch out for: does it work with spaces in the path to the
> > source or binary dir ?
>
> I tested that now and needed the following in KDE4Macros.cmake:
>    qt4_get_moc_inc_dirs(_moc_INCS)
>    set(_incs)
>    foreach(_inc ${_moc_INCS})
>       set(_incs "${_incs}\;${_inc}")
>    endforeach(_inc ${_moc_INCS})
>
> changing that to:
>    set(_incs)
>    GET_DIRECTORY_PROPERTY(_inc_DIRS INCLUDE_DIRECTORIES)
>    FOREACH(_current ${_inc_DIRS})
>       SET(_incs "${_incs}\;-I\;${_current}")
>    ENDFOREACH(_current)
>
> saves ~15s total time spent in cmake.

Cool :-)

> and then I'm passing
>       -DQT_MOC_INCS="${_incs}"
> to the cmake command
>
> then in kde4automoc.cmake I need to do:
> STRING(REPLACE "\\ " " " MOC_FILES "${MOC_FILES}")
> STRING(REPLACE "\\ " " " QT_MOC_INCS "${QT_MOC_INCS}")
>
> 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.

> > > save on IO at cmake time. (Optimizing cmake performance is guesswork or
> > > do you have any way to gather better data?)
> >
> > I used valgrind. But this doesn't really help for IO.
>
> 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.

> 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 ?

Alex