automoc v2

[Matthias Kretz]

On Tuesday 10 July 2007, Alexander Neundorf wrote:
> On Friday 06 July 2007 18:51, Matthias Kretz wrote:
> > 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).

Yes, build time got noticably slower and would have gotten even slower with 
the features I introduced to the C++ base automoc.

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

Yes. As long as automoc somehow can guess that the header belongs to the 
target. Which is almost impossible to _know_ without parsing C++.

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

Yes, the custom target simply had a dependency on the main target. Does cmake 
figure out the dependencies for the target at make time? Because otherwise 
renaming a header file would have the same effect only that it's the .cpp 
which included the header file before would now be named as the offender.

There are two downsides of using a custom target:
a) a lot of I/O at cmake time
b) the automoc target is not remade on /fast

The current setup still has one dependency problem though: make doesn't know 
that the .moc includes in the .cpp files are generated by creating the 
_automoc.cpp file and therefore does not wait for kde4automoc to finish 
before compiling the other sources. By making the automoc a custom target 
that can be fixed because then all of the target depends on the automoc. Is 
there another way?
ADD_CUSTOM_COMMAND(TARGET target PRE_BUILD ...) doesn't work :-(

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

I still think adding headers to the list of sources of a target is awkward and 
not at all self-explanatory. Adding headers to a macro that has moc in the 
name says so much more.
We could switch back to not scanning header files automatically but I think it 
only makes it harder to get right then.

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

Thanks. Changed it now.

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

Yeah, fixed with the change above.

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

On IRC I heard that kde4automoc.cmake was complete magic to somebody. OTOH I 
think all KDE developers will be able to understand the code of kde4automoc 
with little effort (the hardest part is to understand what the moc is and how 
it has to be used).
The problem is probably more to understand what happens at cmake time and what 
at make time...

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

That might be interesting IMO. We should just provide one file that documents 
where to find a given macro...

> P.S. I just noticed, you already committed

Yes, I needed to unbreak the build on Windows...

-- 
________________________________________________________
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/20070712/6e491197/attachment.pgp