On 11/22/2011 10:03 PM, Alexander Neundorf wrote:
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 added special handling now for the case that basename_p.moc is included with
Qt4.
Your new commits work with the parts of the frameworks branch affected
by this, yes.
However, there are still many places where the foo.moc file is expected
to be the result of moc'ing the header, which causes errors like this:
In file included from
/home/stephen/dev/build/qt48/kf5/tier1/libkdbus/kdbus_automoc.cpp:2:0:
/home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.cpp:
In static member function 'static void
KDBusInterProcessLock::qt_static_metacall(QObject*, QMetaObject::Call,
int, void**)':
/home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.cpp:55:22:
error: invalid use of incomplete type 'struct KDBusInterProcessLockPrivate'
/home/stephen/dev/build/qt48/kf5/tier1/libkdbus/../../../../../src/kf5/tier1/libkdbus/kdbusinterprocesslock.h:30:7:
error: forward declaration of 'struct KDBusInterProcessLockPrivate'
Fixed by changing the include from foo.moc to moc_foo.cpp of course.
This is due to the use of Q_PRIVATE_SLOT. I've just added a testcase to
the branch.
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/FakeHelperProx
y.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?
Please have a look at the current AutomocIncludedDotMocFileHandling branch and
see if there are still things missing.
I'll try building frameworks and see what still fails. I do get an error
in solid which again is due to including the foo.moc file and expecting
that to be the result of moc'ing the header. It only works currently due
to a quirk in the include order in that file, so I don't think it's
worth working around or testing.
Thanks,
Steve.
--
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:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
