Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Sunday 01 June 2008 3:02:11 pm Christian Ehrlicher wrote: Alexander Neundorf schrieb: On Thursday 29 May 2008, Christian Ehrlicher wrote: Tanguy Krotoff schrieb: On Thu, May 29, 2008 at 8:48 PM, [EMAIL PROTECTED] wrote: The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a pretty hard one. I simply would like other devs not to spend time on such stupid issues, so how can this be prevented? We hit this problem some time ago and fixed it locally. FindQt4.cmake from kdelibs has a fix for this - I thought alex already merged this back to FindQt4 from cmake. I try to merge partly from time to time, but the differences have become quite big, also because the one from cmake must be more general than the one from KDE (for KDE it's ok if FindQt4.cmake just supports the Qt versions we require, i.e. currently = 4.3.0) So there are some things which will stay different. np, but the ndebug thing should be easy to merge, or? CMake's UseQt4.cmake had that fix more than a week before KDE's FindQt4.cmake, so it seems it got merged the other way. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
Alexander Neundorf schrieb: On Thursday 29 May 2008, Christian Ehrlicher wrote: Tanguy Krotoff schrieb: On Thu, May 29, 2008 at 8:48 PM, [EMAIL PROTECTED] wrote: The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a pretty hard one. I simply would like other devs not to spend time on such stupid issues, so how can this be prevented? We hit this problem some time ago and fixed it locally. FindQt4.cmake from kdelibs has a fix for this - I thought alex already merged this back to FindQt4 from cmake. I try to merge partly from time to time, but the differences have become quite big, also because the one from cmake must be more general than the one from KDE (for KDE it's ok if FindQt4.cmake just supports the Qt versions we require, i.e. currently = 4.3.0) So there are some things which will stay different. np, but the ndebug thing should be easy to merge, or? Christian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
This thread contained another issue related to UseQt4.cmake and FindQt4.cmake:
I wrote a bug report here http://public.kitware.com/Bug/view.php?id=7123
If you don't want that you don't have to use UseQt4.cmake and use
FindQt4.cmake directly.
There you have fine grained control over that.
I want to use UseQt4.cmake since it defines important things:
- QT_DEBUG/QT_NO_DEBUG
- add ${QT_QTMAIN_LIBRARY} if under Windows
- all the -DQT_GUI_LIB, -DQT_CORE_LIB...
I was not using UseQt4.cmake until I encounter some issues under MinGW
as QT_DEBUG/QT_NO_DEBUG were not defined.
Probably QT_DEBUG/QT_NO_DEBUG should be moved to FindQt4.cmake as it
is important.
--
Tanguy Krotoff [EMAIL PROTECTED]
+33 6 68 42 70 24
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
Your patch doesn't work with build systems that have configurations (Visual
Studio, XCode, etc..). Adding -DQT_DEBUG or -DQT_NO_DEBUG cannot rely on
CMAKE_BUILD_TYPE.
What's wrong with leaving it in UseQt4.cmake? In general, things work better
if you use UseQt4.cmake (not only because of QT_DEBUG/QT_NO_DEBUG).
Clint
On Thursday 29 May 2008 12:25:53 pm Tanguy Krotoff wrote:
This thread contained another issue related to UseQt4.cmake and
FindQt4.cmake:
I wrote a bug report here http://public.kitware.com/Bug/view.php?id=7123
If you don't want that you don't have to use UseQt4.cmake and use
FindQt4.cmake directly.
There you have fine grained control over that.
I want to use UseQt4.cmake since it defines important things:
- QT_DEBUG/QT_NO_DEBUG
- add ${QT_QTMAIN_LIBRARY} if under Windows
- all the -DQT_GUI_LIB, -DQT_CORE_LIB...
I was not using UseQt4.cmake until I encounter some issues under MinGW
as QT_DEBUG/QT_NO_DEBUG were not defined.
Probably QT_DEBUG/QT_NO_DEBUG should be moved to FindQt4.cmake as it
is important.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Thu, May 29, 2008 at 8:48 PM, [EMAIL PROTECTED] wrote: Your patch doesn't work with build systems that have configurations (Visual Studio, XCode, etc..). Oups... I never use Visual Studio and others. What's wrong with leaving it in UseQt4.cmake? In general, things work better if you use UseQt4.cmake (not only because of QT_DEBUG/QT_NO_DEBUG). Then why separate UseQt4 and FindQt4? For example, Phonon (I didn't wrote it ;) does not use UseQt4.cmake and probably many other Qt apps do the same. The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a pretty hard one. I simply would like other devs not to spend time on such stupid issues, so how can this be prevented? -- Tanguy Krotoff [EMAIL PROTECTED] +33 6 68 42 70 24 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
Tanguy Krotoff schrieb: On Thu, May 29, 2008 at 8:48 PM, [EMAIL PROTECTED] wrote: The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a pretty hard one. I simply would like other devs not to spend time on such stupid issues, so how can this be prevented? We hit this problem some time ago and fixed it locally. FindQt4.cmake from kdelibs has a fix for this - I thought alex already merged this back to FindQt4 from cmake. Christian signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Thursday 29 May 2008 12:59:18 pm Tanguy Krotoff wrote: On Thu, May 29, 2008 at 8:48 PM, [EMAIL PROTECTED] wrote: Your patch doesn't work with build systems that have configurations (Visual Studio, XCode, etc..). Oups... I never use Visual Studio and others. What's wrong with leaving it in UseQt4.cmake? In general, things work better if you use UseQt4.cmake (not only because of QT_DEBUG/QT_NO_DEBUG). Then why separate UseQt4 and FindQt4? A finder (FindQt4.cmake) is simply supposed to just find things and isn't supposed to modify your compile environment. Qt requires a complicated enough environment to build in that a UseQt4.cmake helps set it up. It also allows you to set it up within a limited scope in case you have a mixed Qt and non-Qt project. Some Qt-only projects may not care about that separation. For example, Phonon (I didn't wrote it ;) does not use UseQt4.cmake and probably many other Qt apps do the same. Yes, I have seen that many projects don't use UseQt4.cmake. In that case, they have the extra work of setting up the compile environment. The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a pretty hard one. Yes, it is a difficult one. It would be nice to be able to somehow put them into the QT_DEFINITIONS variable, but CMake doesn't support that. CMake 2.4.8 put them in CMakeCache.txt under CMAKE_CXX_FLAGS_config But, yesterday, another user brought up an issue that resulted from that. http://www.cmake.org/pipermail/cmake/2008-May/022023.html CMake 2.6 has a new SET_PROPERTY(...), which I think is a good fit. And this is what the current UseQt4.cmake uses. I simply would like other devs not to spend time on such stupid issues, so how can this be prevented? This stuff is better documented in 2.6 than it has ever been before. http://www.cmake.org/HTML/cmake-2.6.html#module:FindQt4 There were/are some other websites that docuemented or gave examples without using UseQt4.cmake, which may have led to more people not using it. But some people are getting it right. http://da-crystal.net/GCMS/blog/cmake-amp-qt4-modules/ Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
Again on the INCLUDE_DIRECTORIES(${QT_${module}_INCLUDE_DIR}) from UseQt4.cmake
Since it is confirmed that Trolltech and kdelibs devs take care about
the #include QtCore/Q...
Will a patch like this would be OK?
It simply add a variable set to ON by default.
If OFF then UseQt4.cmake does not do
INCLUDE_DIRECTORIES(${QT_${module}_INCLUDE_DIR})
And maybe one day, this variable will be set to OFF by default...
--
Tanguy Krotoff [EMAIL PROTECTED]
+33 6 68 42 70 24
include_qt_dirs.patch
Description: Binary data
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Tuesday 27 May 2008 9:53:34 am Tanguy Krotoff wrote:
Again on the INCLUDE_DIRECTORIES(${QT_${module}_INCLUDE_DIR}) from
UseQt4.cmake Since it is confirmed that Trolltech and kdelibs devs take
care about the #include QtCore/Q...
Yes, Qt does take care with their public headers to let you do that.
But, it is interesting that most of the Qt examples don't follow this
convention.
There are 3 conventions in the Qt examples (from most common to least common):
1. #include QtGui
2. #include QWidget
3. #include QtGui/QWidget
Both 1 and 2 require the include paths you're trying to get rid of.
Will a patch like this would be OK?
It simply add a variable set to ON by default.
If OFF then UseQt4.cmake does not do
INCLUDE_DIRECTORIES(${QT_${module}_INCLUDE_DIR})
If we do this, I'd rather have a variable initially unset. Then let you set
it to exclude the inlude paths.
And maybe one day, this variable will be set to OFF by default...
I don't think we can ever make it the default.
I'm curious what the timings are with and without the include paths. Can you
give some data?
If I remember right, this thread started by talking about compile times.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
I'm curious what the timings are with and without the include paths. Can you give some data? If I remember right, this thread started by talking about compile times. That's right! I just tried on phonon-vlc-mplayer http://code.google.com/p/phonon-vlc-mplayer/ the timing argument just is not an argument as I thought: 1) with no Qt modules included $time make real2m57.113s - 177s user2m42.906s sys 0m12.297s 2) with all Qt modules included $time make real3m5.236s - 185s user2m49.619s sys 0m13.941s As you see, there is almost no difference, not even 5%. Historically I was convince that timing differences where huge: on another project, 2 years ago, using SCons, a colleague convince me that using #include QtGui/Q.. was useful with compilation time almost divided by 2. I guess after this small test, that the good timings that we got were due to SCons not handling -I in a proper way. (SCons is/was not scalable) I think the best now is probably not to modify UseQt4.cmake and I will stick with my small macro that optimize the include path as I prefer to have a smaller include path (more readable and easier to debug). -- Tanguy Krotoff [EMAIL PROTECTED] +33 6 68 42 70 24 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On 19.05.08 21:19:20, Bill Hoffman wrote: Tanguy Krotoff wrote: What about my problem? I've just added a small macro that remove all the useless include dirs without touching UseQt4.cmake: http://code.google.com/p/phonon-vlc-mplayer/source/browse/trunk/cmake/ReduceQtIncludeDirs.cmake What do you think about it? I guess it will be OK, as long as Trolltech has cleaned up all of the .h files in Qt itself. Yes they are and AFAIK there's a policy within TT that you can't use the short form for any public header. The same thing is true for KDE's kdelibs module, no public header is allowed to #include QMainWindow they all have to work with just passing -I/some/path/to/qt/include. Andreas -- Your best consolation is the hope that the things you failed to get weren't really worth having. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Tue, May 20, 2008 at 10:29 AM, Andreas Pakulat [EMAIL PROTECTED] wrote: Yes they are and AFAIK there's a policy within TT that you can't use the short form for any public header. The same thing is true for KDE's kdelibs module, no public header is allowed to #include QMainWindow they all have to work with just passing -I/some/path/to/qt/include. Do you know why this policy is not followed by *_p.h and *.cpp files? when compiling Qt-4.4.0, QMake includes all the modules (i.e -I/usr/lib/qt4/include/QtGui -I/usr/lib/qt4/include/QtCore...) -- Tanguy Krotoff [EMAIL PROTECTED] +33 6 68 42 70 24 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On 20.05.08 14:56:57, Tanguy Krotoff wrote: On Tue, May 20, 2008 at 10:29 AM, Andreas Pakulat [EMAIL PROTECTED] wrote: Yes they are and AFAIK there's a policy within TT that you can't use the short form for any public header. The same thing is true for KDE's kdelibs module, no public header is allowed to #include QMainWindow they all have to work with just passing -I/some/path/to/qt/include. Do you know why this policy is not followed by *_p.h and *.cpp files? Because its not needed, compilation of the .cpp and _p.h files in the Qt sources is under the control of Trolltech (for KDE its likewise under control of the kde devs), so they (we) can make sure that the buildsystem sets the needed include paths for using just #include QWidget. The problem with installed/public header files is that you never know who uses them with what buildsystem and wether or not he/his buildsystem sets the needed additional include paths. So its important that when one public header include's another one he does this in a way that compilation of some third party sources only fails if there's no -I switch for Qt at all. Andreas -- Keep emotionally active. Cater to your favorite neurosis. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Monday 19 May 2008, you wrote:
Phonon is about to move to kdesupport (i.e. outside KDE), and or that to
work it will use the new KDE-independent automoc4 (also in kdesupport
since two weeks), which supports all automoc features. We (KDE) will do a
reparate release of automoc4 in the foreseeable future, so it can be used
by non-KDE projects.
http://websvn.kde.org/trunk/kdesupport/
This is a really good news! it will help my work on VLC and MPlayer
backends for Phonon http://code.google.com/p/phonon-vlc-mplayer/
and other Qt4 only projects
Cool :-)
As I have the right guy to discuss this in front of me, I noticed that
UseQt4.cmake includes all the Qt modules inside the include path. This
allows devs to write #include QMainWindow directly instead of
#include QtGui/QMainWindow
Problem is that it increases compilation time (more path in the
include path) + the make line is less readable (longer)
If you don't want that you don't have to use UseQt4.cmake and use
FindQt4.cmake directly.
There you have fine grained control over that.
So my request would be to remove
INCLUDE_DIRECTORIES(${QT_${module}_INCLUDE_DIR}) from UseQt4.cmake
People that still want to use #include QMainWindow can manually add
include_directories(${QT_QTGUI_INCLUDE_DIR}) in their CMakeLists.txt
What do you think about this?
By default this is not possible since it would break backwards compatibility.
It could be possible as an option for UseQt4.cmake, but I guess Clinton should
comment on that (he is the official FindQt4.cmake maintainer)
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Mon, May 19, 2008 at 8:20 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
If you don't want that you don't have to use UseQt4.cmake and use
FindQt4.cmake directly.
There you have fine grained control over that.
I want to use UseQt4.cmake since it defines important things:
- QT_DEBUG/QT_NO_DEBUG
- add ${QT_QTMAIN_LIBRARY} if under Windows
- all the -DQT_GUI_LIB, -DQT_CORE_LIB...
I was not using UseQt4.cmake until I encounter some issues under MinGW
as QT_DEBUG/QT_NO_DEBUG were not defined.
Probably QT_DEBUG/QT_NO_DEBUG should be moved to FindQt4.cmake as it
is important.
The only problem with UseQt4.cmake is the INCLUDE_DIRECTORIES() which
increases compilation time.
--
Tanguy Krotoff [EMAIL PROTECTED]
+33 6 68 42 70 24
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Monday 19 May 2008 12:46:04 pm Tanguy Krotoff wrote:
On Mon, May 19, 2008 at 8:20 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
If you don't want that you don't have to use UseQt4.cmake and use
FindQt4.cmake directly.
There you have fine grained control over that.
I want to use UseQt4.cmake since it defines important things:
- QT_DEBUG/QT_NO_DEBUG
- add ${QT_QTMAIN_LIBRARY} if under Windows
- all the -DQT_GUI_LIB, -DQT_CORE_LIB...
I was not using UseQt4.cmake until I encounter some issues under MinGW
as QT_DEBUG/QT_NO_DEBUG were not defined.
Probably QT_DEBUG/QT_NO_DEBUG should be moved to FindQt4.cmake as it
is important.
The only problem with UseQt4.cmake is the INCLUDE_DIRECTORIES() which
increases compilation time.
Can you explain why?
Is it because you have dependent modules that you don't use directly, that
need to be turned on for linking?
In the past, I've thought of modifying UseQt4.cmake to partially turn on
dependent modules automatically (for linking), which would allow not having
as many include directories.
This would allow for behavior closer to what qmake does.
Thanks,
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Monday 19 May 2008 12:46:04 pm Tanguy Krotoff wrote:
On Mon, May 19, 2008 at 8:20 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
If you don't want that you don't have to use UseQt4.cmake and use
FindQt4.cmake directly.
There you have fine grained control over that.
I want to use UseQt4.cmake since it defines important things:
- QT_DEBUG/QT_NO_DEBUG
- add ${QT_QTMAIN_LIBRARY} if under Windows
- all the -DQT_GUI_LIB, -DQT_CORE_LIB...
I was not using UseQt4.cmake until I encounter some issues under MinGW
as QT_DEBUG/QT_NO_DEBUG were not defined.
Probably QT_DEBUG/QT_NO_DEBUG should be moved to FindQt4.cmake as it
is important.
The only problem with UseQt4.cmake is the INCLUDE_DIRECTORIES() which
increases compilation time.
UseQt4.cmake in CVS has been recently patched to reduce the number of include
directories specified in certain cases.
For example, if QT_USE_QTUITOOLS=1 but QT_USE_XML=0, the QtXml includes and
defines are no longer added. If you still want the includes, because you use
QtXml directly, you can set QT_USE_XML=1. qmake makes developer that
explicit too.
Hope that solves your problem.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
UseQt4.cmake in CVS has been recently patched to reduce the number of include
directories specified in certain cases.
I don't want to reduce them, I want to get rid of them...
Hope that solves your problem.
There is no problem, and if there is one it is definitly not specific to me.
Let me explain again :)
Remember the good old time:
Qt previous to version 4 was just a huge lib, there was only one
include directory with everything inside.
Writing Qt-3 #include code looked like this:
#include qmainwindow.h
#include qstring.h
Qt-4 has been splitted into several libraries: QtCore, QtGui... so
there are one include directory for each module.
Writing Qt #include code now looks like:
#include QMainWindow
#include QString
or
#include QtGui/QMainWindow
#include QtCore/QString
Writing #include QMainWindow, #include QString... leads to have an
include path -I/usr/lib/qt4/include/QtGui -I/usr/lib/qt4/QtCore up to
18! (and obviously more modules will come over time)
Another solution is to write #include QtGui/QMainWindow, #include
QtCore/QString...
This may you need one and only one include path: -I/usr/lib/qt4/include/
What are the advantages of the latter solution?
Well, as I said before:
- Reduced compilation time, this is obvious as you have a smaller include path
- Cleaner/smaller make compilation line
Never got a problem because of a stupid -DBLABLA left somewhere?
Now it is easier to find as you don't get a make line that takes all
your terminal
Your make line is again readable, so less pain
Why Trolltech kept the possibility to write #include QMainWindow?
for compatibility reasons I guess, old habits...
KDE doesn't have to necessary follow the same path as QMake
Writing #include QtGui/QMainWindow instead of #include QMainWindow
keeps the code compatible and I personally find it cleaner: I can see
from where my includes come from and it helps me organizing them
cleanly: #include QtCore/... first, then QtGui, then QtNetwork...
To summarize I think it is a cleaner/better solution for free.
A good transition for UseQt4.cmake would be a simple variable:
if (QT_INCLUDE_DIRS_ON)
INCLUDE_DIRECTORIES(${QT_${module}_INCLUDE_DIR})
endif (QT_INCLUDE_DIRS_ON)
What about my problem? I've just added a small macro that remove all
the useless include dirs without touching UseQt4.cmake:
http://code.google.com/p/phonon-vlc-mplayer/source/browse/trunk/cmake/ReduceQtIncludeDirs.cmake
What do you think about it?
--
Tanguy Krotoff [EMAIL PROTECTED]
+33 6 68 42 70 24
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
Tanguy Krotoff wrote: What about my problem? I've just added a small macro that remove all the useless include dirs without touching UseQt4.cmake: http://code.google.com/p/phonon-vlc-mplayer/source/browse/trunk/cmake/ReduceQtIncludeDirs.cmake What do you think about it? I guess it will be OK, as long as Trolltech has cleaned up all of the .h files in Qt itself. If there are any files in Qt that use QMainWindow or something without a directory on it, then things will break. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Saturday 17 May 2008, Tanguy Krotoff wrote:
Hello
I've noticed some lake of features inside FindQt4.cmake qt4_automoc macro
This patch intend to fix this.
(patch against CMake 2.6.0)
How current qt4_automoc works:
Looks for files that contain string: #include *.moc
Issues:
- With QMake, it is possible to specify also #include moc_*.cpp
Current qt4_automoc does not handle this.
Here the fix:
-STRING(REGEX MATCHALL #include +[^ ]+\\.moc[\] _match
${_contents})
+STRING(REGEX MATCHALL #include +([^
]+\\.moc[\])|(\moc_+[^ ]+\\.cpp[\]) _match ${_contents})
- Current qt4_automoc doesn't check if the .h corresponding to the
*.moc file exists.
Sometimes the Q_OBJECT macro is directly inside the .cpp file and
there is no .h file
Here the fix:
+ IF(NOT EXISTS ${_header})
+ SET(_header ${_abs_PATH}/${_basename}.cpp)
+ ENDIF(NOT EXISTS ${_header})
As you see .cpp extension is hardcoded but I don't think there is the
need for using CMAKE_CXX_SOURCE_FILE_EXTENSIONS as QMake probably
don't support it.
Test:
I managed to compile Phonon library that relies exclusively on
#include moc_*.cpp and #include *.moc feature
qt4_automoc() doesn't support all the fancy automoc features of qmake or KDE4s
automoc and I don't feel like adding it.
Phonon is about to move to kdesupport (i.e. outside KDE), and or that to work
it will use the new KDE-independent automoc4 (also in kdesupport since two
weeks), which supports all automoc features. We (KDE) will do a reparate
release of automoc4 in the foreseeable future, so it can be used by non-KDE
projects.
http://websvn.kde.org/trunk/kdesupport/
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
