make KDE4_AUTOMOC compatible to qmake

David Faure faure at kde.org
Tue Jun 26 16:19:39 CEST 2007


On Tuesday 26 June 2007, Thiago Macieira wrote:
> David Faure wrote:
> >On Tuesday 26 June 2007, Thiago Macieira wrote:
> >> Matthias Kretz wrote:
> >> >don't have David's mail here for replying to it...
> >> >
> >> >but attached is a patch to create the .moc file from the .cpp file if
> >> > the .cpp file matches ^\s*Q_OBJECT. For moc_foo.cpp files it always
> >> > creates it from the .h file. That way you can include both
> >> >#include "moc_foo.cpp"
> >> >#include "foo.moc"
> >> >
> >> >and with that include the moc generated code from the .cpp and the .h
> >> > files. (If I understood correctly that's compatible with qmake.)
> >>
> >> *.cpp files must not be included. They must be compiled on their own.
> >>
> >> Only *.moc files should be included.
> >
> >You're talking about qmake? I tested with foo.cpp including both
> > moc_foo.cpp and foo.moc (when both foo.cpp and foo.h have a Q_OBJECT)
> > and it worked fine.
> 
> No, I'm talking about us. We shouldn't include other .cpp files.

We need a solution for Q_OBJECT in both foo.h and foo.cpp  ... 
if the only mechanism we have is to create a foo.moc then we can't 
handle that situation (which is however very common, when having public
API and internal classes; requiring ugly foo_p.h files currently).

> It's a lot easier to write rules when you can do wildcard matching.

cmake rules? or independent scripts? moc_*.cpp files are in the builddir anyway...

> >But I guess that doesn't prove much, I might have been linking
> > moc_foo.cpp twice into the binary?
> 
> If you had, you'd get linker errors.

So you want to deliberately be incompatible with qmake?
This makes cases like phonon, kdchart, and kdgantt harder to handle for
no good reason IMHO.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


More information about the Kde-buildsystem mailing list