[cmake-developers] cmake automoc breaks kde

[Stephen Kelly]

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?

> 
> -----------------------------
> 
> 
> diff --git a/tier1/solid/solid/backends/fakehw/fakedevice.cpp
> b/tier1/solid/solid/backends/fakehw/fakedevice.cpp
> index dce82e4..1e5781a 100644
> --- a/tier1/solid/solid/backends/fakehw/fakedevice.cpp
> +++ b/tier1/solid/solid/backends/fakehw/fakedevice.cpp
> @@ -335,5 +335,5 @@ QObject *FakeDevice::createDeviceInterface(const
> Solid::DeviceInterface::Type &t
>      return iface;
>  }
>  
> -#include "backends/fakehw/fakedevice.moc"
> +#include "backends/fakehw/moc_fakedevice.cpp"
>  #include "backends/fakehw/fakedevice_p.moc"
> 
> 
> This one was actually a bug, this one works now with the updated branch.

Cool.

> 
> 
> -----------------------------
> 
> diff --git a/tier1/solid/solid/devicemanager.cpp
> b/tier1/solid/solid/devicemanager.cpp
> index 06919c3..0fd8c89 100644
> --- a/tier1/solid/solid/devicemanager.cpp
> +++ b/tier1/solid/solid/devicemanager.cpp
> @@ -288,6 +288,6 @@ void
> Solid::DeviceManagerStorage::ensureManagerCreated()
>      }
>  }
>  
> -#include "devicenotifier.moc"
> +#include "moc_devicenotifier.cpp"
>  #include "moc_devicemanager_p.cpp"
> 
> In this case at least the error message is early and to the point:
> "AUTOMOC: error: /home/alex/src/CMake/tests/solid/solid/devicemanager.cpp:
> The file includes the moc file "devicenotifier.moc", which seems to be the
> moc file from a different source file. This is not supported. Include
> "devicemanager.moc" to run moc on this source file."
> 
> An alternative fix is the following:
> 
> diff -rbup solid.orig/solid//solid/CMakeLists.txt
> solid//solid/CMakeLists.txt
> --- solid.orig/solid//solid/CMakeLists.txt      2011-11-23
> 11:32:15.000000000 +0100
> +++ solid//solid/CMakeLists.txt 2011-11-30 21:48:13.000000000 +0100
> @@ -42,6 +42,7 @@ set(solid_LIB_SRCS
>     managerbase.cpp
>     device.cpp
>     devicemanager.cpp
> +   devicenotifier.h
>     deviceinterface.cpp
>     genericinterface.cpp
>     processor.cpp

Seems out of place there. Again I prefer the direct include, but good that 
there's multiple solutions.

> 
> 
> diff -rbup solid.orig/solid//solid/devicemanager.cpp
> solid//solid/devicemanager.cpp
> --- solid.orig/solid//solid/devicemanager.cpp   2011-11-30
> 03:08:04.000000000 +0100
> +++ solid//solid/devicemanager.cpp      2011-11-30 21:49:17.000000000
> +0100 @@ -288,6 +288,5 @@ void Solid::DeviceManagerStorage::ensure
>      }
>  }
>  
> -#include "devicenotifier.moc"
>  #include "moc_devicemanager_p.cpp"
>  
> 
>> You can decide how much of this should be covered in the backwards
>> guarantee automoc feature and how much will require fixing solid instead.
> 
> Yes, I'm quite undecided.
> The breakages above are caused by forward declarations in the header
> (which I can't detect), and by moc'ing files which are not known to cmake
> at all (devicenotifier.h, and there is no devicenotifier.cpp).
> 
> 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.

> 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. The rest of the frameworks branch mocs fine with your 
branch.

> 
> OTOH, if we add two ParseCpp()s, one with the behaviour from 2.8.6, which
> can be optionally enabled, if Qt4 is used, it will be much harder to
> generate proper warnings in that compatibility mode.

I prefer the proper warnings personally.

By the way, there is another migration vector to consider: qt4_automoc 
macros to CMAKE_AUTOMOC feature. qt4_automoc works with *.moc style, but not 
moc_*.cpp style includes. I have tested Grantlee with the new feature. I've 
attached the porting patch.

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. The solution is just to remove the .moc includes 
anyway.

Thanks,

Steve.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: grantlee.patch
Type: text/x-patch
Size: 3560 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20111201/e2da959c/attachment-0002.bin>