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

[Ralf Wildenhues]

Hi Gergely,

* RISKÓ Gergely wrote on Thu, Jul 09, 2009 at 10:41:26PM CEST:
> >
> > 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.

However, not all platforms have pkg-config.  I didn't have it on my
MinGW install, for example.  And I didn't really want to install it
there either.

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

Ah, ok.  I didn't know of this convention.  All I know about QT is from
the one application we've written, and we haven't really looked for how
things are otherwise done in this part of the software world (simply
because we didn't need to, not for any deeper reason).

> I wanted to
> create an implementation with exactly the same file name semantics as
> already taught in various Qt documentation.

Alright, understood.

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

So I gather the latter is done only if bar.cpp contains a class
declaration that is not supposed for other files, but still uses
the QT object model?

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

Wait.  I did make a mistake there in my writeup, sorry about that.
They should have been added to nodist_foo_SOURCES only, that's what
we actually do in the code; also to BUILT_SOURCES and CLEANFILES,
so that they are built early enough and that distcheck passes.

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

Hmm; this sounds like we really should get moc authors to output
dependency rules, preferably as a side effect.  Ideally it'd support
the -MT -MD -MP -MF flags, with gcc's semantics ... ;-)
Or plain -M, that would be a suitable minimal basis.

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

I'd like to defer answering this question until I've at least understood
the functionality your patches offer.

Cheers,
Ralf