make KDE4_AUTOMOC compatible to qmake

[Matt Rogers]

On Jul 1, 2007, at 3:19 PM, Matthias Kretz wrote:

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

I'd like to see that feature. :)
--
Matt