automoc v2

[Matthias Kretz]

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

I've tried hard to see whether the problem exists for normal builds but have 
not been able to break it. It seems to break only for /fast builds.

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

:-( I think it's better the way it is now then. Building the /fast target 
twice is still faster than building without /fast.

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

Right, you don't only list all the implementation files but all files that 
belong to the target...
Ok, I'm fine with removing KDE4_MOC_HEADERS then.

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

That's what kde4automoc already does. You can have e.g. two source files that 
include the .moc and those two sources are passed to kde4_add_executable. 
Compiles. Now you remove the .moc includes and recompile the target (even 
with /fast if you want to) and kde4automoc will #include the two moc files 
into <targetname>_automoc.cpp. This will get compiled and linked into the 
target. Since all not-included mocs are compiled in one go you don't lose 
much.

> If the tool kde4automoc would be written without Qt, e.g. STL only, then
> this could theoretically also be used to build Qt itself...

I don't think you'll be able to easily substitute the STL for QtCore in 
kde4automoc.

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

Yes, I meant that we need it when we start implementing macros as C++ plugins 
to cmake.

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

Thanks, changed my cmake code now.

-- 
________________________________________________________
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/20070713/2fe18db9/attachment.pgp