[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