On Thursday, October 04, 2012 12:49:34 PM Stephen Kelly wrote:
The distros people are using to develop KDE 4.10 ship with CMake 2.8.7 (eg
latest Ubuntu). I think that's a more significant fact.
it is hard to understand for me why this is a so hard argument. Building KDE
already requires
On Monday, January 23, 2012 09:39:07 Stephen Kelly wrote:
Hi,
I wrote a script to remove most of the moc includes from kdelibs
I probably missed something, but why remove them? Wouldn't that mean slower
compilation?
and
transform the remaining ones from incorrect to correct form (usually
On Tuesday 27 May 2008, Alexander Neundorf wrote:
#include QtCore/QObject
#ifdef Q_OS_UNIX
class Foo:public QObject
{
signals:
void fooChanged();
};
#endif
Maybe I'm missing something, but you don't have the Q_OBJECT macro
there.
Andras
--
Quanta Plus developer -
On Sunday 18 May 2008, Matthias Kretz wrote:
automoc4 uses the include directories as specified by
include_directory. At least that's what I wrote and expect the code
to do. :-)
Take a look at the generated target_automoc.cpp.files file. Its
second line contains all the include directories
On Monday 19 May 2008, Matthias Kretz wrote:
You mean the line under MOC_INCLUDES? Yes, it contains the path to
kdebase/workspace/libs, but this doesn't change the fact that the
installed one is taken and not the one from the kdebase source dir.
My question was not whether it contains that
On Sunday 11 May 2008 00:58:38 Alexander Neundorf wrote:
If you experience any problems with automoc, please let us know at
kde-buildsystem@kde.org (or here).
Here is a problem: kdebase fails to build if there are some older
include/solid/control/ifaces around.
The error is:
cd
On Saturday 10 May 2008, Alexander Neundorf wrote:
Do you mean testing if it is found automatically ?
I mean if it is found by the rest of KDE. I build and install everything
into /opt/kde4, including kdesupport. The question is if I need to clear
the build dir/install dir prior to testing, or
Hi,
does anyone have an idea what is wrong here?
Andras
-- Forwarded Message --
Subject: [quanta-devel] Unable build kdewebdev in trunk after windows
related build system
Date: Thursday 27 March 2008
From: Keith Isdale [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hi,
I
On Thursday 27 March 2008, Christian Ehrlicher wrote:
Von: Andras Mantia
Hi,
does anyone have an idea what is wrong here?
svn up kdelibs - this was added some weeks ago and is needed to get
the correct install locations on windows
Thanks, this is why I did not see the error
On Thursday 14 February 2008, Benjamin Reed wrote:
Those functions are all static, in libkommanderplugin, so I presume
they shouldn't actually be directly available to kommanderwidget?
They should, but maybe they are not exported on OSX? I have no problems
compiling this code on Linux.
On Sunday 10 February 2008, Allen Winter wrote:
We, kdepim, very much want to continue building against kdelibs 4.0.
Which means we need to keep a copy. I'm fine with that.
Yes, and I'm sure you're not the only one wanting to do something like
that[*]. But this is the way to go. :)
Andras
On Tuesday 30 October 2007, Thiago Macieira wrote:
Discussion moved from kde-core-devel. Link to thread:
http://lists.kde.org/?t=11934324191r=1w=2
So let's get back here: was anything done regarding this issue, namely
have a way that KDE (including kdesupport) can be built and used
On Tuesday 06 November 2007, you wrote:
btw, I install KDE as a user and I don't run into this problem. My
LD_LIBRARY_PATH is empty and my ld.so.conf doesn't contain the place
where I installed KDE to, so not everyone is affected.
Don't you have by any chance the kdesupport libraries and
On Tuesday 16 October 2007, Andreas Pakulat wrote:
On 16.10.07 12:07:25, Andras Mantia wrote:
On Tuesday 16 October 2007, Andras Mantia wrote:
So what do I need 0.9.16a EXACTLY or =0.9.16?
I think I know the problem, LIB_SUFFIX is not detected correctly (I
have the libraries in /usr
Hi,
today I run into the following error:
[ 46%] Building CXX object
workspace/kwin/CMakeFiles/kdeinit_kwin.dir/workspace.o
/data/development/build/kde-trunk/kdebase/workspace/kwin/kwinadaptor.h:69:
error: ‘KWinInternal’ has not been declared
On Wednesday 23 August 2006 07:53, Christian Ehrlicher wrote:
T_QTUITOOLS_LIBRARY is added with target_link_libraries (see
CMakeLists.txt). Maybe cmake did not find qtuitools for you. Take a
look at CMakeCache.txt.
What Qt version do you use?
Christian
You should build the Qt tools as well
On Friday 28 April 2006 15:23, you wrote:
Andras Mantia wrote:
Previously we had an install-exec target for make which installed
only libraries and applications (and modules of course). This is
very handy if you have lot of data that does not change, but you
have to install the executables
On Friday 28 April 2006 16:07, Dirk Mueller wrote:
On Friday, 28. April 2006 14:30, Andras Mantia wrote:
It already does that (as I understood starting from cmake 2.4.0),
but it still prints out everything, even if it's not installed for
real, and this is slow, for example in KDevelop
On Wednesday 26 April 2006 23:13, Brad King wrote:
Andras Mantia wrote:
I'm using now cmake 2.4.0-beta and still have problems with the
include directories (as I described before).
Please post a follow-up to the previous discussion describing changes
seen with cmake 2.4 if any
On Thursday 27 April 2006 19:04, Alexander Neundorf wrote:
On Thursday 27 April 2006 17:47, Andras Mantia wrote:
On Thursday 27 April 2006 17:45, Brad King wrote:
Thanks, now I've been able to duplicate the problem. You should
have seen it with earlier CMake versions too, but it only
Hi,
I'm using now cmake 2.4.0-beta and still have problems with the include
directories (as I described before). But what I want to report is a
possible bug in finding the dependencies.
In a subdir (called lib) I have the following rules:
include_directories(
${CMAKE_CURRENT_SOURCE_DIR}
Hi,
(I admit I still use the old cmake snapshot release, not 2.4.0, so
correct me if this was changed/fixed/implemented).
If you have a builddir != srcdir setup and use ui or kcfg files, they
are generated in the builddir. This means every CMakeList.txt file must
have the
On Tuesday 25 April 2006 20:31, Alexander Neundorf wrote:
But maybe this would be a bit too much magic behind the scenes. As it
is now it is easy to understand what happens. If you need some
include dir, add it with INCLUDE_DIRECTORIES().
Do you also think that including the current source dir
On Tuesday 25 April 2006 20:45, Alexander Neundorf wrote:
On Tuesday 25 April 2006 19:41, Andras Mantia wrote:
On Tuesday 25 April 2006 20:31, Alexander Neundorf wrote:
But maybe this would be a bit too much magic behind the scenes.
As it is now it is easy to understand what happens
On Tuesday 25 April 2006 21:27, Brad King wrote:
Andras Mantia wrote:
On Tuesday 25 April 2006 20:45, Alexander Neundorf wrote:
On Tuesday 25 April 2006 19:41, Andras Mantia wrote:
Do you also think that including the current source dir and the
binary dir associated with the current source
Hi
There is (another) feature that existed in unsermake, but as I see is
missing in cmake. If something failed, unsermake displayed the whole
command that failed.
With cmake, once it fails, you need to run make again with VERBOSE=1.
David's post shows that this can cause your source to build.
Hi,
I experience an error when compiling the snapshot. I saw similar errors
in the past that gone away when cleaning the svn source. Now with a
cleaned source dir and a new build dir, I get the following error:
-- Build files have been written to: /data2/kde4/build/kdelibs4_snapshot
make[2]:
On Tuesday 11 April 2006 16:41, Brad King wrote:
This was fixed in CMake CVS on 2006-03-30. It no longer attempts to
use relative paths between the source and build trees. Relative
paths are only safe between directories both contained in the source
tree or both contained in the build tree.
Hi,
Many 64bit distributions use lib64 for 64bit libraries and lib for 32
bit ones. AFAIK there are some using lib32 for 32bit and lib for 64 bit
ones. Recently I fixed the automake system for KDE 3.5 to detect if
your distribution is using a suffix or not and use the same for KDE.
This is
On Tuesday 11 April 2006 20:33, Alexander Neundorf wrote:
With cmake ?
I don't have a 64bit system here, but I think it checks both
versions. Laurent knows more about this, he has 64bit system
available AFAIK.
Yes. I have a 64bit SUSE which is using lib64 for all 64 bit libraries.
After
On Tuesday 11 April 2006 20:30, William A. Hoffman wrote:
Perhaps it should search all lib64 first, instead of alternating?
Does this sound like what is happening on your machine?
No, the problem for me (right now) is not where cmake looks to find the
libaries, but the default library suffix
Ok, after I'm through building kdelibs, I tried kdebase. Now after an
svn-clean svn up. I get a similar error as yesterday with kdelibs:
-- Generating done
-- Build files have been written to: /data2/kde4/build/kdebase
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory
On Tuesday 21 March 2006 20:08, Alexander Neundorf wrote:
The reason why I moved QTDIR to the first position is because it is
simple. On my system the Qt3 bin/ dir is in the PATH, while the Qt4
bin/ dir isn't. Is this broken ?
On SuSE they both point to the default Qt3 installation.
On Tuesday 21 March 2006 20:26, Andras Mantia wrote:
Another problem is that now it works inconsistently. If you pass the
-DQT_QMAKE_EXECUTABLE with the right path when running cmake it will
find it, but as soon as you run make, it will complain again.
I withdraw this. Now it seems to work
On Tuesday 21 March 2006 20:01, Alexander Neundorf wrote:
Is it possible that you have some leftovers of an in-source build or
an out-of-source build from 16th march to 19th march in your source
tree ? If there are some, they usually hurt.
Most probably this was the cause.
Simple solution:
35 matches
Mail list logo
