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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
-
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
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 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
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,
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
20 matches
Mail list logo
