[cmake-developers] cmake automoc breaks kde
david.cole at kitware.com
Thu Dec 1 15:27:53 EST 2011
On Thu, Dec 1, 2011 at 3:18 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> 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
>> 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.
> Powered by www.kitware.com
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> Follow this link to subscribe/unsubscribe:
You have two topics on the stage with common parent commits:
AutomocIncludedDotMocFileHandling (not presently in next) and
RestoreAutmocKDECompatibility (which is presently in next)...
Are you planning to keep both of these, or are you focused on the
continuing topic AutomocIncludedDotMocFileHandling with the intention
of removing RestoreAutmocKDECompatibility from the stage...?
Also, could you remove TI_DSP_Compiler from the stage, and use some
other mechanism (github, gitorious, ...) to communicate changes with
the guy on the other side of that branch? The topic stage should
really only be used for things that are intended for 'next' in the
near future. Brad and I don't want to get in the habit of ignoring old
topic branches week after week when we review stuff on the stage.
More information about the cmake-developers