Re: [PATCH 0/8] Qt's Meta Object Compiler (MOC) integration

[RISKÓ Gergely]

On Thu, 9 Jul 2009 20:41:38 +0200, Ralf Wildenhues <address@hidden> writes:

> Hello Gergely,
>
> * Gergely Risko wrote on Thu, Jul 09, 2009 at 01:16:19PM CEST:
>> I've patched automake to include support for Qt's MOC.  I've introduced
>> a new prog_QTSOURCES variable for the user to specify the Qt based
>> sources.  I've modified the texinfo documentation, added tests.
>
> Thank you for doing all of this work!
>
> First off, I haven't looked at it at all yet.  Also, I don't want to
> discourage you either, but still: I've found using moc to be quite
> trivial without any large changes to Automake at all.  We use it in
> one of our projects like this:
>
> configure.ac uses macros from pkg.m4 and bnv_have_qt.m4 for QT3:

As you mention later, this bnv thing is a bit outdated (qt3 only), I
really don't think that it has to be ported to qt4, since qt4 has
pkg-config and it just works.

> Makefile.am uses something like this:
>
>   bin_PROGRAMS = foo ...
>   foo_SOURCES = \
>           $(foo_moc_in_sources) \
>           $(foo_moc_sources) \
>           foo_other_sources.cpp \
>           foo_other_sources.h ...
>
>   foo_moc_sources = $(foo_moc_in_sources:.h=.moc)
>
>   foo_moc_in_sources = \
>           header.h \
>           ...
>
>   SUFFIXES = .cpp .moc .h
>
>   .h.moc:
>           $(MOC) -i $< -o $@
>
> The *.cpp files typically include the *.moc file at the end.

Actually this is the limitation, that I don't like at all.  In the Qt
world including the moc file at the end of the cpp is done if (and only
if) the cpp itself get moc'd, but not if a header file.  I wanted to
create an implementation with exactly the same file name semantics as
already taught in various Qt documentation.

foo.h -> moc_foo.cpp
bar.cpp -> bar.moc and #include <bar.moc> at the end of bar.cpp

And by adding foo_moc_sources to foo_SOURCES you will get them
distributed which is a bit useless in Qt's case, because you need qt-dev
anyway for the linking and qt-dev includes the moc tool.

> The automatic dependency tracking will record the dependencies upon
> the .moc files.

Yes, but while we are at dependencies: both your and my implementation
has the same bug: if foo.h is included in bar.h and we generate
moc_bar.cpp (or in your case bar.moc) from bar.h then any change in
foo.h should trigger the recreating of moc_bar.cpp (or bar.moc).

In my understanding, for this we have to add dependency generation to
moc.  I haven't looked into the source code of moc yet and haven't
consulted the Qt guys about their willingness, but now I have a simpler
idea, a little (automake distributed) moc-dep.sh shell script, which:
  - calls gcc preprocessor on the bar.h >/dev/null -> we get dependency
    info as a side effect,
  - then calls moc.

> For QT4, one needs to adjust the configure.ac stuff (I still need to
> finish my work on this and feedback to the bnv_have_qt.m4 authors),
> and add e.g. $(CPPFLAGS) to the $(MOC) command line.  Also, as an
> example, you can use something like
>   $PKG_CONFIG --variable=moc_location QtCore
> to detect the moc that comes with a QT4 install.

Yes, this is an other option too for looking up the moc, and I think my
macro should be modified to use this as the first guess instead of my
current implementation (which I just have stolen from the vala guys and
then s/vala/moc/g edited it :)).

> It might be a couple of weeks until I have time to look at this any
> further.

Ok, thanks for any review.  I think that the diff is small enough that
it worth the effort to have real moc support.  Why the patch is a bit
big is because of documentation and that has to be added anyway because
your solution is simple enough if you have it, but novice users won't
figure it out on their own.

Have I sold you the idea of builtin Qt support? (Of course if the code
itself is bad then I have to fix it.)  If I have, then probably I will
continue with adding some .qrc and .uic support while waiting for you.

Thanks for the fast reply,
Gergely