[cmake-developers] cmake automoc breaks kde

Stephen Kelly steveire at gmail.com
Tue Nov 22 15:25:35 EST 2011


On 11/22/2011 08:43 PM, Alexander Neundorf wrote:
> On Tuesday 22 November 2011, Stephen Kelly wrote:
>> On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
> ...
>>> Please give the RestoreAutmocKDECompatibility branch on cmake stage a
>>> try. It should work again, but print a warning if a file includes a
>>> moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro.
>>>
>>> For Qt5 I'd prefer to not support that anymore.
>>> I.e. moc_foo.cpp ->   header, foo.moc ->   source file.
>>>
>>> Alex
>> I tried that branch. It doesn't build the frameworks branch for me.
>
> I found the mistake !
>
> When I wrote that mail two weeks ago it was the RestoreAutmocKDECompatibility
> branch. This got merged into master in the meantime.
>
> Once your Qt5 branch was merged, I created a new branch named
> AutomocIncludedDotMocFileHandling.
>
> This is the branch I'm talking about.
>
> Alex

Actually I've been using that branch all along.

Now when I try to build the frameworks branch using the cmake next 
branch, I get:

AUTOMOC: error: 
/home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The 
file includes the moc file "kdirwatch_p.moc", which seems to be the moc 
file from a different source file. This is not supported. Include 
"kdirwatch.moc" to run moc on this source file.

I then get a good deal of

/home/stephen/dev/src/kf5/tier1/libkauth/HelperProxy.cpp:0: Note: No 
relevant classes found. No output generated.
Generating FakeHelperProxy.moc
/home/stephen/dev/src/kf5/tier1/itemmodels/src/kcheckableproxymodel.cpp:0: 
Note: No relevant classes found. No output generated.
Generating moc_kdescendantsproxymodel.cpp
/home/stephen/dev/src/kf5/tier1/libkauth/backends/fakehelper/FakeHelperProxy.cpp:0: 
Note: No relevant classes found. No output generated.

The warnings are good because they indicate doing it the wrong way.

As I noted in the other mail, I'll fix these issues in the frameworks 
branch.

Do you want testcases for them in cmake to workaround it there?




More information about the cmake-developers mailing list