automoc v2

[Alexander Neundorf]

Hi Matthias,

On Thursday 12 July 2007 05:18, Matthias Kretz wrote:
...
> 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

No, at cmake time.

> 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

Does this mean parallel builds are broken ? This would be a serious problem.

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

I don't see another way right now.

> ADD_CUSTOM_COMMAND(TARGET target PRE_BUILD ...) doesn't work :-(

Yes, as the docs state this is not possible for makefiles.

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

You could also see it this way, that the KDE4_ADD_EXECUTABLE/LIBRARY etc. 
macros just handle moc completely automatically, you just have to list all 
the files you care about.

How about that: we get rid of automoc completely, i.e. no need anymore to put 
the "include foo.moc" in any file, but we just scan all interesting files 
for "Q_OBJECT" and if found, moc them.
Ah, well, this would increase build time, since the moc files would be 
compiled separately. I guess this wasn't a good idea.

It's just, KDE4_MOC_HEADERS(target file1 file2 ...) is so similar to 
QT4_WRAP_CPP(srcsList file1 file2 ...)and doesn't actually do something 
different in effect, you specify files which you want to have moced, once 
with a target and once with a list.

KDE4_MOC_HEADERS(kfoo widget1.h widget2.h)
KDE4_ADD_EXECUTABLE(kfoo ${SRCS})

Is basically almost identical to this: 

SET(SRCS ${SRCS} widget1.h widget2.h)
KDE4_ADD_EXECUTABLE(kfoo  ${SRCS})

There is also the issue that with KDE4_MOC_HEADERS() you can use a target name 
before you add the target, which while this is actually the purpose, is 
different to all other cmake commands.



> > 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 can understand that, I just wanted to note that I'm a bit concerned that 
it's getting quite complicated.
If the tool kde4automoc would be written without Qt, e.g. STL only, then this 
could theoretically also be used to build Qt itself...

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

I've never done that and I'm not really sure what is required to build such a 
command. I'll give it a try when I find time.

> We should just provide one file that documents where to find a given 
macro...

Huh ?
All macros starting with KDE4_ are in KDE4Macros.cmake, and all macros being 
in KDE4Macros.cmake should start with KDE4.
This kind of namespacing should be used for all cmake module files.

Performance tip:
LIST(APPEND srcs widget.h)
is for large lists much faster than
SET(srcs ${srcs} widget.h)

Bye
Alex