Alexander Neundorf wrote:
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
On Friday 02 December 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
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
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
+++
Alexander Neundorf wrote:
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
On Thu, Dec 1, 2011 at 3:18 PM, Alexander Neundorf neund...@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
---
On Thursday 01 December 2011, David Cole wrote:
...
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
On Wednesday 30 November 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Tuesday 22 November 2011, Stephen Kelly wrote:
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:
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 @@
On Tuesday 22 November 2011, Stephen Kelly wrote:
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
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
On Wednesday 02 November 2011, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
On Monday 31 October 2011, David Faure wrote:
This is a typical (kde) case
On 11/22/2011 06:20 PM, Alexander Neundorf wrote:
Using Qt5 or Qt4 ?
Qt4.
There seems to be several problems:
* KDE does include foo.moc if it wants the header file to be moc'd.
This is 'incorrect' compared to what qmake expects, which would be a
moc_foo.cpp include.
Yes.
* Some places
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/22/2011 06:20 PM, Alexander Neundorf wrote:
Using Qt5 or Qt4 ?
Qt4.
There seems to be several problems:
* KDE does include foo.moc if it wants the header file to be moc'd.
This is 'incorrect' compared to what qmake expects,
On 11/22/2011 07:10 PM, Alexander Neundorf wrote:
find #include (.*).moc - generate moc for \\1.cpp
Was there a reason for preventing this?
We can do that, but how can that work ?
I mean, this will generate code for a class which is declated in a different
source file, so it is unknown in
On Tuesday 22 November 2011, Alexander Neundorf wrote:
On Tuesday 22 November 2011, Stephen Kelly wrote:
...
This is not uncommon in both KDE and in Qt itself, or any other project
where it makes sense to put a QObject-inherited class in the _p.h as an
internally used class. See for
On 11/22/2011 07:37 PM, David Faure wrote:
On Tuesday 22 November 2011 14:33:25 Stephen Kelly wrote:
I think in many cases,
fixing KDE will just be removing the explicit include foo.moc which is
intended to run moc on foo.h, and let the automatic moc'ing do the work.
No, to include
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
Alexander Neundorf wrote:
Test added, works.
What is not working right now is including someotherfile.moc. I could add
special handling for including thisfile_p.moc (as opposed to
moc_thisfile_p.cpp, which works).
Yes, this is the issue that makes the build break in the frameworks branch.
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
On Tuesday 22 November 2011, Stephen Kelly wrote:
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
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
On Wednesday 02 November 2011, Stephen Kelly wrote:
On 11/02/2011 06:32 PM, David Faure wrote:
#include foo.moc
#include moc_foo.cpp
This would have generated twice the same moc file, I think. IMO this
is really confusing.
Well there is no reason to include both, unless
On Sunday 06 November 2011, Thiago Macieira wrote:
On Sunday, 6 de November de 2011 18:42:42 Alexander Neundorf wrote:
On Wednesday 02 November 2011, Stephen Kelly wrote:
On 11/02/2011 06:32 PM, David Faure wrote:
#include foo.moc
#include moc_foo.cpp
This would have
On 11/02/2011 06:32 PM, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
No, it's the other way around, in KDE. $ grep Q_OBJECT kautosavefile.*
kautosavefile.h: Q_OBJECT $ grep moc kautosavefile.cpp #include
kautosavefile.moc
If it did additionally other things,
On 11/02/2011 06:32 PM, David Faure wrote:
#include foo.moc
#include moc_foo.cpp
This would have generated twice the same moc file, I think. IMO this is
really confusing.
Well there is no reason to include both, unless you have Q_OBJECT in the .cpp
file too:-)
I'm sure I've
On Monday 31 October 2011, David Faure wrote:
Hi Alex,
The latest changes in cmake-git (probably the merge of
AutomocFindQ_OBJECTAlwaysInHeader) break the compilation of kde-frameworks.
This is for fixing http://public.kitware.com/Bug/view.php?id=12533
Before:
Generating
25 matches
Mail list logo
