[cmake-developers] cmake automoc breaks kde
Alexander Neundorf
neundorf at kde.org
Thu Dec 1 15:18:12 EST 2011
On Thursday 01 December 2011, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Thanks.
> >
> > diff --git a/tier1/solid/solid/audiointerface.cpp
> > b/tier1/solid/solid/audiointerface.cpp
> > index ddf6cbc..98e42b2 100644
> > --- a/tier1/solid/solid/audiointerface.cpp
> > +++ b/tier1/solid/solid/audiointerface.cpp
> > @@ -67,4 +67,4 @@ Solid::AudioInterface::SoundcardType
> > Solid::AudioInterface::soundcardType() cons
> >
> > return_SOLID_CALL(Ifaces::AudioInterface *, d->backendObject(),
> >
> > InternalSoundcard, soundcardType());
> >
> > }
> >
> > -#include "audiointerface.moc"
> > +#include "moc_audiointerface.cpp"
> >
> > An alternative way to fix this is to include <QVariant> in the header and
> > not include the moc file here at all.
>
> Personally I prefer fixing the moc include so that it's still possible to
> forward declare in the header file. It is very common to forward declare in
> KDE. I don't know how likely this is to occur though. However, including
> the correct include file is an easy fix. We can start the updating of the
> KDE moc strategy soon I think.
>
> You said that you can't detect this case, but why do you have to? Isn't
> there already a check for the Q_OBJECT macro in the cpp file? Wouldn't the
> logic be 'if the <basename>.moc file is included but there is no Q_OBJECT
> in the header, then moc the <basename>.h and put the result in
> <basename>.moc', or does that conflict with another rule?
I'll put some more work in it over the weekend.
Probably something like this should work.
Or "if it's not my own .moc-file, never assume it's the .moc-file from another
cpp-file (end of story here with Qt5), but try whether it could be the moc-
file from a header".
...
> > So I think with the current cmQtAutomoc::ParseCpp() I can't handle and
> > can't detect and warn for those cases. Which would mean that automoc in
> > 2.8.7 will not be able to substitute the standalone automoc4 (as 2.8.6
> > was). This is not really good.
> > But at least now in 2.8.7 automoc behaves more like what the
> > documentation said already in 2.8.6, so it could be argued that
> > everything which was working before is still working now and everything
> > which does not work anymore was working only by accident.
> > Which seems kind of ok,
>
> Yes, I think the situation is pretty good with it now, though we haven't
> tried to build the rest of KDE with it.
Let me know how it works.
> > but this still means that even if we start to
> > require cmake 2.8.7 for kdelibs4, we still need the standalone automoc
> > (which I don't feel like maintaining).
>
> Well, kdelibs4 is not really going to get any more releases. I'm not sure
> it makes sense to change the cmake requirement for it, but that's more a
> topic for kde-buildsystem. If you really meant frameworks branch, then I'd
> say we fix solid and move on.
No, I meant kdelibs4.
Still people will continue to build against it for some time (it's not even
dead yet), and the cmake stuff in it should stay maintained.
This would be easier if there was only one group of files (the ones in e-c-m),
instead of two (kdelibs4 and e-c-m).
See the mail for the FindQtMobility.cmake review...
...
> There are a great deal of warnings like:
>
> /home/stephen/dev/src/grantlee/templates/lib/template.cpp:0: Note: No
> relevant classes found. No output generated.
>
> because moc is run on the cpp file (it is also run on the header of
> course).
>
> Is it possible to give a better warning from cmake in those cases? If not,
> it's probably a big deal.
"not a big deal", right ?
> The solution is just to remove the .moc includes anyway.
Yes.
Alex
More information about the cmake-developers
mailing list