automoc v2

[Alexander Neundorf]

Hi,

...back from 3-day holiday, noticing a lot has happened on the KDE lists...

On Friday 06 July 2007 18:51, Matthias Kretz wrote:
> Hi,
>
> attached you'll find the next generation of automoc

Patch looks good so far.

> I replaced kde4automoc.cmake with a C++/QtCore based program that can run
> more efficient.

...which is good, but this doesn't help cmake time (but build time, which is 
also good).

> Instead of creating a <targetname>.automoc file that is added to the target
> I create a <targetname>_automoc.cpp file now that is compiled and linked
> into the target. This file #includes all moc files that are not included by
> other source files. This way the automoc can, at make-time, decide what
> mocs need to be compiled explicitly and linked into the target.
>
> E.g. the following is possible now:
> foo.h:
> class A : public QObject
> {
>   Q_OBJECT
> ...
> };
>
> foo.cpp does not #include "foo.moc"
>
> run make - everything compiles and links fine (without mentioning the
> header in KDE4_MOC_HEADERS either since the new automoc looks at all
> corresponding header files from the .cpp files by itself)

This means if there's a header which needs to be mocced but this isn't done 
via including the moc file this will be detected automatically ?

> now change foo.cpp to #include "foo.moc"
>
> running make now will just work, even with the /fast target.
>
> Next change I did was to create a <targetname>_automoc.cpp.files file to
> pass the moc includes and the source files that belong to the target to the
> automoc. I could have kept it on the command line but I got a report that
> the command line was already too long for Windows' cmd.exe.
>
> Implementation details:
> - The messages of the automoc are written using cmake -E cmake_echo_color,
> so the automoc correctly colorizes its messages now.
> - The moc QProcesses are started in parallel (up to 10).

This is cool :-)

> Please test and let me know if you have any problems (you might have to
> remove some explicit QT4_WRAP_CPP calls from CMakeLists.txt now). I'd like
> to commit soon, as this is supposed to fix compilation on Windows again...



> No, it doesn't. Because I made the _automoc.cpp depend on all .cpp files
> that are passed as sources plus all corresponding existing .h files. If

Existing at cmake time...
This isn't really good, so we still have some part of the the problem we had 
with the old automoc.
I think this wasn't the case for the first version of the new automoc I sent, 
there a custom target for every target was used. So there was a reason that 
it was a custom target instead of a custom command which creates a file. Even 
if it's slower, it will be correct, so it probably needs to be a custom 
target.

For the mocing headers which are not included via automoc...
I understand correctly that this is currently done for headers where a 
corresponding source file is listed as source ?
I think doing this is not a good idea. While this will work in most cases, it 
will not work if there are headers which have no corresponding .cpp file and 
which are not automoced. While this is probably a rare case, it still will 
not work and will be hard to debug ("it works for most headers,but some 
headers are not moced, what am I doing wrong ?").
I suggest to parse only files for "include ...moc..." or "Q_OBJECT" which have 
been listed as source file, i.e. if there are headers which are not automoced 
then they have to be listed as sources. This will make it easier to 
understand how moc is handled. Then we also don't need KDE4_MOC_HEADERS() and 
KDE4_GET_CUSTOM_TARGET_PROPERTY().

> Ok, I thought I could make the automoc target depend on the .files file.
> But all those are touched when cmake is run. 

When using FILE(WRITE ...) the file is unconditionally written.
If you use CONFIGURE_FILE(), it is only written if it has actually changed. 
You can either configure the contents of the file, or FILE(WRITE ...) to a 
temporary file and the CONFIGURE_FILE( COPYONLY) this temporary file to 
the .files file.

> I'm about to change the dependency back to a dep on srcdir/CMakeLists.txt

Hmm, this sounds strange.
Somebody might do include(SomeFile.cmake) which holds the variable settings 
and then this dependency doesn't work as exptected.

> mean that the build becomes a bit slower again.

A more generic note:
I wanted to keep the buildsystem for KDE4 easy to understand with generic 
cmake knowledge. A lot of things have been done since then and not everything 
is as straight forward as it was in the beginning, e.g. RPATH and other 
things. Now we moved automoc into an external tool (kde4automoc.cmake), and 
now we are about to move a part of it into an executable which is build as 
part of kdelibs. I also already thought about turning it somehow into a 
binary. It should also be possible to write a cmake command which can be 
loaded as plugin by cmake itself. Buth then again I thought this makes the 
build to hard to understand...

Regarding cmake speed:
IIRC using valgrind I found out (it's already some time ago) that quite some 
time is spent handling all the long argument lists in the cmake scripts, i.e. 
we have many fooSrcs variables which are given to several macros. Internally 
every cmake variable is a std::string. This is then transformed into a 
std::vector<std::string> by splitting it at the ";" whenever required. With 
some amount of work something could be improved there.

Second point: in CMake/Source/cmListFileCache.cxx there is already some code 
to cache the cmake files. With some (moderate) amount of work probably a 
cache of all parsed files could be added (one big file containing the parsed 
contents of all cmake files).
Is there a standard way to save STL types like vector>string> into a file ?

Third point: maybe we can write a cmake command plugin which does a lot of the 
handling for all kde4 targets (i.e. kde4_check_executable_params(),  
kde4_handle_automoc(), kde4_create_final_files() ), so a lot of the 
string-vector conversions would fall away.

4th point: I can't tell how much these changes improve cmake time

Bye
Alex

P.S. I just noticed, you already committed