On 04.07.08 14:40:51, Marcus Hufgard (Kalkwerk Hufgard GmbH) wrote:
Hi!
Why do we have 2 version of FindBoost.cmake.
One in kdelibs and one in kdevplatform. Shouldn't we have only one
version of it in kdelibs?
I would prever the version of kdevplatform.
I want to change this. Is it
Hi,
glibconfig.h is needed to compile anything against glib headers but the
finding of that file is only optional in FindGLIB2.cmake. Also it only
looks into the include dir itself, but distro's start to put such
headers into prefix/lib/libname/include/ because its
architecture-dependant.
The
On 18.06.08 09:19:59, Benjamin Reed wrote:
On Wed, Jun 18, 2008 at 8:38 AM, Allen Winter [EMAIL PROTECTED] wrote:
I remember Alex and myself fighting with FindGLIB2 previously.
Probably the following is where you need to hack:
find_path(GLIB2_INTERNAL_INCLUDE_DIR glibconfig.h
On 16.06.08 00:35:09, Alexander Neundorf wrote:
On Sunday 15 June 2008, Andreas Pakulat wrote:
On 15.06.08 16:56:33, Allen Winter wrote:
On Sunday 15 June 2008 16:15:38 David Johnson wrote:
p.s. I did not realize that the old style lowercase headers were a
political issue. I
On 15.06.08 16:56:33, Allen Winter wrote:
On Sunday 15 June 2008 16:15:38 David Johnson wrote:
p.s. I did not realize that the old style lowercase headers were a
political
issue. I apologize for bringing up this topic. Shall I revert the few
changes
I have made?
Don't revert.
:
On Wednesday 04 June 2008, Andreas Pakulat wrote:
Hmm, interesting my KDELibsDependenciesInternal.cmake in
/usr/share/apps/cmake/modules contains references to my
build/kdelibs directory. That is surely wrong.
Yes I saw that here as well.
For which libs
On 04.06.08 13:35:30, David Faure wrote:
On Tuesday 03 June 2008, Brad King wrote:
David Faure wrote:
Currently the
only way to override what the NO_DEFAULT_PATH stuff finds is to set the
result variable in the cache by hand for each and every library. If you
(as a project dev) want
On 04.06.08 14:25:09, David Faure wrote:
On Wednesday 04 June 2008, Andreas Pakulat wrote:
Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or
is the reason
rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more priority
than qt's [old] phonon
On 04.06.08 18:06:00, Michael Pyne wrote:
On Wednesday 04 June 2008, David Faure wrote:
On Wednesday 04 June 2008, Andreas Pakulat wrote:
But that means modifying global variables, i.e. affecting all other
calls to find_library? This doesn't sound right. When looking for
libbz2 we
On 03.06.08 21:02:50, David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS
Hi,
since some time (can't say wether its a week or two or a month), I'm
getting this with latest CMake from 2.6 branch:
WARNING: Cannot generate a safe linker search path for target kcm_access
because there is a cycle in the constraint graph:
dir 0 is [/home/andreas/kde4/lib]
dir 2 must
On 03.06.08 21:30:11, David Faure wrote:
On Tuesday 03 June 2008, Andreas Pakulat wrote:
Hi,
since some time (can't say wether its a week or two or a month), I'm
getting this with latest CMake from 2.6 branch:
WARNING: Cannot generate a safe linker search path for target
On 15.04.08 19:19:45, Alexander Neundorf wrote:
On Monday 14 April 2008, Andreas Pakulat wrote:
Hi,
so today I found that there are actually problems with cmake 2.6 and
dependency scanning.
a) after changing an installed header the .moc files for headers that
include the updated
Hi,
so today I found that there are actually problems with cmake 2.6 and
dependency scanning.
a) after changing an installed header the .moc files for headers that
include the updated header are not re-generated which might cause
problems when you do ABI changes (like removing a method) on the
On 11.04.08 13:34:21, Friedrich W. H. Kossebau wrote:
What is the difference between the build version and api version? Is build
version the long major.minor.patch-level, and api version just major.minor?
No, SOVERSION is a version number on the .so file you create and is
usually understood as
On 03.04.08 22:42:12, Pau Garcia i Quiles wrote:
I think that would make life easier for downstream packagers. The
other options are:
- they maintain their own CPack stuff on their own repository, totally
unrelated to KDE
- they keep packaging as they have done until now, as if CPack 2.6
On 10.02.08 13:45:10, David Johnson wrote:
We are still having linking problems over at FreeBSD. Several libraries and
apps are being linked to KDE3 by mistake. I need to find a way to fix this.
Please help me if you can.
The problem arises because KDE3 is installed to /usr/local, along
On 10.02.08 14:29:21, David Johnson wrote:
On Sunday 10 February 2008, Andreas Pakulat wrote:
On 10.02.08 13:45:10, David Johnson wrote:
Can you check wether link_directories(${KDE4_LIB_DIR}) helps? Thats
something that is needed for CMake 2.6 support anyway and if we have a
need
On 10.02.08 15:55:43, David Johnson wrote:
On Sunday 10 February 2008, Andreas Pakulat wrote:
On 10.02.08 13:45:10, David Johnson wrote:
What do I do to ensure that the KDE4 libraries (-L/usr/local/kde4/libs)
comes before the KDE3 libraries (-L/usr/local/lib)? Please provide me
On 10.02.08 16:36:20, David Johnson wrote:
On Sunday 10 February 2008, Andreas Pakulat wrote:
On 10.02.08 15:55:43, David Johnson wrote:
CMakeFiles/kcm_filetypes.dir/kserviceselectdlg.o -L/usr/local/lib
-L/usr/local/kde4/lib -lQtCore -lpthread -lkdecore -lkdeui -lkio -lkparts
-lQtCore
On 09.02.08 10:01:54, Allen Winter wrote:
With a fresh kdepim and CMake 2.4.8 I get -lgeneral added to all link lines.
Of course, there is no such library and the build fails. I know others have
had similar issues, although I don't know what CMake version they were using.
I then installed
On 05.02.08 23:41:43, Alexander Neundorf wrote:
On Tuesday 29 January 2008, Andreas Pakulat wrote:
On 29.01.08 18:11:48, David Faure wrote:
On Monday 28 January 2008, Andreas Pakulat wrote:
On 28.01.08 10:32:15, Andreas Pakulat wrote:
There are a couple of ways to fix
On 06.02.08 00:00:55, Alexander Neundorf wrote:
On Tuesday 05 February 2008, Andreas Pakulat wrote:
On 05.02.08 23:41:43, Alexander Neundorf wrote:
...
No, we shouldn't add LINK_DIRECTORIES() somewhere global. We would do it
only for KDE4_LIB_DIR, but the same breakage can happen
Hi,
CMake CVS changed some behaviour in how it treats
target_link_directories. Specifically it now doesn't -L switches to the
linker call unless one explicitly calls link_directories() and sets the
needed paths.
This breaks building any module in KDE4 (except kdelibs) because we get
some
On 28.01.08 16:04:06, David Faure wrote:
On Monday 28 January 2008, Andreas Pakulat wrote:
Opinions? Better Ideas?
Does replacing -lsolid with ${KDE4_SOLID_LIBS} work?
After all we already have those variables, so we can avoid -lfoo completely I
think.
Its not quite that easy. The thing
On 28.01.08 10:32:15, Andreas Pakulat wrote:
There are a couple of ways to fix this:
a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add
link_directories calls for kde libdir and qt libdir in all
CMakeLists.txt all over trunk/.
I must be blind. FindKDE4Internal.cmake already
On 28.01.08 23:31:34, Andreas Pakulat wrote:
On 28.01.08 10:32:15, Andreas Pakulat wrote:
There are a couple of ways to fix this:
a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add
link_directories calls for kde libdir and qt libdir in all
CMakeLists.txt all over trunk
On 12.01.08 17:42:28, Christian Ehrlicher wrote:
Hi,
I know we discussed this already, but I'm very unhappy with the current
solution.
The problem is (for all who don't remember) that we want to install the
shared libs into /bin on windows. When we install the shared libs into
/lib, we've
On 13.01.08 01:25:18, Andreas Pakulat wrote:
On 12.01.08 17:42:28, Christian Ehrlicher wrote:
Hi,
I know we discussed this already, but I'm very unhappy with the current
solution.
The problem is (for all who don't remember) that we want to install the
shared libs into /bin on windows
On 21.12.07 15:36:23, Thomas McGuire wrote:
Hello,
recently I changed the XML D-Bus interface from being hand-written to being
auto-generated by calling qt4_generate_dbus_interface on the kmkernel.h
header file.
Other applications in KDEPIM also use this XML interface, for example
On 13.12.07 17:53:49, Allen Winter wrote:
On Thursday 13 December 2007 14:54:28 David Faure wrote:
On Thursday 13 December 2007, Allen Winter wrote:
Howdy,
I don't think our buildsystem handles the OpenGL you can
build in Qt4 vs. the one that comes with a distro.
I don't
On 08.11.07 16:22:03, David Faure wrote:
On Thursday 08 November 2007, Patrick Spendrin wrote:
SVN commit 734310 by sengels:
changing install locations of dll's to bin
M +5 -1 apps/dolphin/src/CMakeLists.txt
M +5 -1 apps/keditbookmarks/CMakeLists.txt
M +5 -1
On 23.09.07 14:50:47, Allen Winter wrote:
I'm using cmake from cvs and it found a problem in kdelibs/kjs/CMakeLists.txt:
Warning: Source file
/data/kde/trunk/KDE/kdelibs/build-gcc/kjs/kjs_automoc.cpp is listed
multiple times for target kjs.
I think this is due to having a library named
On 23.09.07 16:58:37, Matt Rogers wrote:
On Sunday 23 September 2007 13:50:47 Allen Winter wrote:
Howdy,
I'm using cmake from cvs and it found a problem in
kdelibs/kjs/CMakeLists.txt:
Warning: Source file
/data/kde/trunk/KDE/kdelibs/build-gcc/kjs/kjs_automoc.cpp is listed
multiple
On 20.09.07 18:43:25, Alexander Neundorf wrote:
Two more notes:
to run tests (i.e. added via ADD_TEST) it is not necessary to know where the
executable is located. You can run the tests via ctest:
$ ctest- runs all tests in this dir and below
$ ctest -R kio - runs all tests whose
On 22.09.07 00:33:25, Dirk Mueller wrote:
It is not an often done debugging job to debug a heavily eventbased
interactive application (like KDE applications generally are) in a debugger
and stepping through it line by line.
I disagree (but then I've done only one year of KDE development, so
On 19.09.07 21:31:39, Alexander Neundorf wrote:
On Wednesday 19 September 2007 20:51, Andreas Pakulat wrote:
...
Well, I also quite often execute tests manually, especially QtTest based
ones, because that way I can see their full output. And if I'm in
builddir/myplugin/ or builddir
On 19.09.07 20:15:43, Thiago Macieira wrote:
Andreas Pakulat wrote:
Hi,
in kdelibs the CXX and CFLAGS for Debug builds are set to include -g -O2
which breaks debug builds. This way debug builds are usable _only_ for
getting backtraces, but not for actual debugging because this lets gcc
On 19.09.07 22:18:12, David Faure wrote:
On Wednesday 19 September 2007, Andreas Pakulat wrote:
On 19.09.07 20:15:43, Thiago Macieira wrote:
Some flags suggestions:
Release: -O2
RelWithDebugInfo: -g -O2
optimised-but-debuggable: -g -O2 -fno-inline -fno-schedule-insns
-fno
On 19.09.07 18:40:16, Alexander Neundorf wrote:
currently KDE4_ADD_TEST_EXECUTABLE and KDE4_ADD_UNIT_TEST set
EXECUTABLE_OUTPUT_PATH back from bin/ to the current directory.
I think this is a bad idea in general.
In general maybe, but within kde I think its quite ok.
Imagine this cmake
On 31.08.07 17:34:02, Thibault wrote:
No, this patch produce the xml output variant of QTestLib. The log is
save in a file named testname.tml.
Sorry to jump in so late, but how the hell is an xml file more readable
than the simple messages that QTest created until now? Especially I find
it
Hi,
I just re-introduced shared libs in kdevelop4's python plugin (living in
playground/devtools/kdevelop4-extra-plugins/python) and found that the
shared lib for the parser would be built _after_ the one for the duchain
even though the duchain-lib links to the parser lib and uses headers
from
Hi,
I'd like to know why FindStrigi doesn't cache the result of the search,
but instead executes the full search each time any CMakeLists.txt in
kdelibs is touched? Is this just an oversight or is there a real reason?
Its making kdelibs development a slight bit inconvenient because I can't
just
On 02.08.07 21:42:24, Alexander Neundorf wrote:
On Thursday 02 August 2007 14:37, Andreas Pakulat wrote:
Hi,
I'd like to know why FindStrigi doesn't cache the result of the search,
but instead executes the full search each time any CMakeLists.txt in
kdelibs is touched? Is this just
On 10.07.07 22:01:30, Alexander Neundorf wrote:
On Tuesday 10 July 2007 16:08, Andreas Pakulat wrote:
...
I think the macro I came up with causes a full rebuild of the project
using it when touching any of the CMakeLists.txt.
An example is playground/devtools/kdevelop4-extra-plugins/ruby
On 09.07.07 22:35:49, Alexander Neundorf wrote:
On Sunday 08 July 2007 14:53, Andreas Pakulat wrote:
On 08.07.07 20:49:23, Ralf Habacker wrote:
Andreas Pakulat schrieb:
On 08.07.07 19:31:49, Andreas Pakulat wrote:
On 08.07.07 11:06:32, Matt Rogers wrote:
On Jul 8, 2007, at 9:35
On 10.07.07 07:46:35, Ralf Habacker wrote:
Alexander Neundorf schrieb:
On Monday 09 July 2007 17:18, Ralf Habacker wrote:
Andreas Pakulat schrieb:
On 09.07.07 06:49:23, Thiago Macieira wrote:
Andreas Pakulat wrote:
As I tried to explain at the start
On 09.07.07 23:22:23, Alexander Neundorf wrote:
On Monday 09 July 2007 14:22, Andreas Pakulat wrote:
python/parser/CMakeLists.txt with
add_executable(python-parser ${foo_SRCS} )
Then cmake will complain that it doesn't know how to create the files in
foo_SRCS for the python-parser
On 10.07.07 11:20:46, Andreas Pakulat wrote:
On 09.07.07 23:22:23, Alexander Neundorf wrote:
On Monday 09 July 2007 14:22, Andreas Pakulat wrote:
python/parser/CMakeLists.txt with
add_executable(python-parser ${foo_SRCS} )
Then cmake will complain that it doesn't know how
On 07.07.07 00:51:38, Matthias Kretz wrote:
Hi,
attached you'll find the next generation of automoc
I replaced kde4automoc.cmake with a C++/QtCore based program that can run
more
efficient.
I've got one question: Could it be that a change in any CMakeLists.txt
triggers a full rerun of
Hi,
due to a problem (I'd call it a bug actually) in cmake its not possible
to install 2 kde modules where one depends on the other into separate
directories (and separate directories from kdelibs). For packaging KDE
module's however its needed that each module is installed into its own
prefix.
On 08.07.07 11:06:32, Matt Rogers wrote:
On Jul 8, 2007, at 9:35 AM, Andreas Pakulat wrote:
due to a problem (I'd call it a bug actually) in cmake its not
possible
to install 2 kde modules where one depends on the other into separate
directories (and separate directories from kdelibs
On 08.07.07 19:31:49, Andreas Pakulat wrote:
On 08.07.07 11:06:32, Matt Rogers wrote:
On Jul 8, 2007, at 9:35 AM, Andreas Pakulat wrote:
due to a problem (I'd call it a bug actually) in cmake its not
possible
to install 2 kde modules where one depends on the other into separate
On 08.07.07 20:49:23, Ralf Habacker wrote:
Andreas Pakulat schrieb:
On 08.07.07 19:31:49, Andreas Pakulat wrote:
On 08.07.07 11:06:32, Matt Rogers wrote:
On Jul 8, 2007, at 9:35 AM, Andreas Pakulat wrote:
due to a problem (I'd call it a bug actually) in cmake its
On 08.07.07 20:26:34, Andreas Pakulat wrote:
On 08.07.07 19:31:49, Andreas Pakulat wrote:
On 08.07.07 11:06:32, Matt Rogers wrote:
On Jul 8, 2007, at 9:35 AM, Andreas Pakulat wrote:
due to a problem (I'd call it a bug actually) in cmake its not
possible
to install 2 kde modules
On 08.07.07 23:42:24, Thiago Macieira wrote:
Andreas Pakulat wrote:
So using kde4-config --path data as destination for
FindKDevPlatform.cmake is not an option and neither is installing
KDevPlatformConfig.cmake into kdelibs/lib/kdevplatform.
Why not?
$ kde4-config --path data
/home
On 05.07.07 21:09:23, Matt Rogers wrote:
On Jul 5, 2007, at 6:01 PM, Andreas Pakulat wrote:
SVN commit 684033 by apaku:
Add -fPIC, that seems to be the only option to use a static lib in a plugin
on
64Bit platforms
CCing kde-buildsystem because I'm not sure this is the right thing
On 06.07.07 11:26:57, Dirk Mueller wrote:
On Friday, 6. July 2007, Andreas Pakulat wrote:
Add -fPIC, that seems to be the only option to use a static lib in a plugin
on 64Bit platforms
no, link the sources directly instead of adding a static library.
Thats not feasible, because some
SVN commit 684033 by apaku:
Add -fPIC, that seems to be the only option to use a static lib in a plugin on
64Bit platforms
CCing kde-buildsystem because I'm not sure this is the right thing to do.
Making it a shared library is a problem because parts of the code is generated
and the generator
Hi,
I have two problems with the output that the new automoc stuff from
Matthias creates:
a) its not coloured so you can't easily ignore it. Normally in a make
run standard-coloured lines indicate errors or warnings so this is
confusing at first sight. It seems this is some CMake-Source-Internal
On 04.07.07 18:39:20, Matthias Kretz wrote:
On Wednesday 04 July 2007, Andreas Pakulat wrote:
b) Its too long. It contains the full absolute path of the header and
the moc file. IMHO it should be just the filename or if possible the
relative path of the .h to the CMakeLists.txt (i.e
On 04.07.07 20:36:26, Matthias Kretz wrote:
On Wednesday 04 July 2007, Andreas Pakulat wrote:
The idea is ok, but does this also work with make VERBOSE=1? Because
thats the standard cmake way (AFAIK) of getting verbose output.
Yes, that's what I showed in my previous email. Is there any
Hi,
I just wanted to remove the need for knotifyrc to be installed and found
out that the set_properties call in KDE4_ADD_TEST_EXECUTABLE doesn't
have an effect at all. That means
- the executable is put into kdelibs/bin instead of current binary dir
- the -DKDESRCDIR is not included properly, I
On 21.06.07 14:18:03, Thiago Macieira wrote:
Matthias Kretz said:
Hi,
as I just got my second report that phonon doesn't link I thought I'd
better
implement a check that errors out if Qt has been compiled without
visibility
support but KDE is compiled with default hidden
On 21.06.07 15:41:21, Thiago Macieira wrote:
Christian Ehrlicher said:
and while this works on Win32, it breaks on linux because Q_DECL_EXPORT
doesn't evaluate to default-visibility (don't know the gcc command for
that) but to nothing. At least on a default-built qt-copy.
It's not the
On 21.06.07 15:58:45, Andreas Pakulat wrote:
On 21.06.07 15:41:21, Thiago Macieira wrote:
Christian Ehrlicher said:
and while this works on Win32, it breaks on linux because Q_DECL_EXPORT
doesn't evaluate to default-visibility (don't know the gcc command for
that) but to nothing
On 19.06.07 22:36:44, Alexander Neundorf wrote:
On Tuesday 19 June 2007 19:39, Andreas Pakulat wrote:
On 19.06.07 19:08:20, Alexander Neundorf wrote:
...
add_executable(foo EXCLUDE_FROM_ALL main.cpp)
install(TARGETS foo DESTINATION bin)
where the install failed if foo wasn't built
On 19.06.07 10:14:26, David Faure wrote:
On Monday 18 June 2007, Andreas Pakulat wrote:
Hi,
it seems my changes did have an unfortunate impact on installed tests.
Two users reported an installing problem with kdelibs on IRC and it
seems the problem is that knotifytest in knotify/test
On 19.06.07 11:56:32, Olivier Goffart wrote:
Le mardi 19 juin 2007, Andreas Pakulat a écrit :
On 19.06.07 10:14:26, David Faure wrote:
On Monday 18 June 2007, Andreas Pakulat wrote:
Hi,
it seems my changes did have an unfortunate impact on installed tests.
Two users reported
On 19.06.07 19:08:20, Alexander Neundorf wrote:
On Tuesday 19 June 2007 06:15, Andreas Pakulat wrote:
On 19.06.07 11:56:32, Olivier Goffart wrote:
Le mardi 19 juin 2007, Andreas Pakulat a écrit :
On 19.06.07 10:14:26, David Faure wrote:
On Monday 18 June 2007, Andreas Pakulat wrote
Hi,
it seems my changes did have an unfortunate impact on installed tests.
Two users reported an installing problem with kdelibs on IRC and it
seems the problem is that knotifytest in knotify/test is installed. The
problem is that the install() commands in the CMakeLists.txt are not
guarded
On 18.06.07 14:31:09, Andreas Pakulat wrote:
Hi,
it seems my changes did have an unfortunate impact on installed tests.
Two users reported an installing problem with kdelibs on IRC and it
seems the problem is that knotifytest in knotify/test is installed. The
problem is that the install
On 14.06.07 22:15:53, Alexander Neundorf wrote:
On Thursday 14 June 2007 20:59, Andreas Pakulat wrote:
...
So I'll do the rename during the weekend (all of trunk/KDE), as the
KProcess-Stuff is sorted out for kdelibs already. That is wherever
currently kde4_add_test() and add_test
On 08.06.07 00:28:35, Alexander Neundorf wrote:
On Thursday 07 June 2007 07:24, Carsten Niehaus wrote:
Moin
kdelibs from 2 days ago, Qt 4.3-final, CMake 2.4.6. OpenSUSE 10.2, latest
svn of kdeedu.
As you can see here
http://rafb.net/p/KsCM3V63.html
I am using a clean build-dir
On 08.06.07 00:34:17, Alexander Neundorf wrote:
On Thursday 07 June 2007 03:00, David Faure wrote:
The naming is a bit unfortunate IMHO. kde4_add_test is called this way
to look like kde4_add_executable, i.e. build this test program
(which could be automated or interactive). But CMake's
On 05.06.07 19:33:55, Thiago Macieira wrote:
Andreas Pakulat wrote:
Hi,
I'd like to know wether its expected that one needs both kde4_add_test
and add_test to make tests work even if KDE4_BUILD_TESTS was set to off?
If one doesn't tell cmake via add_test() that a testcase exists the make
Hi,
using the kde4_add_test macro works pretty well, except that calling the
test target doesn't build the tests. I talked to Thiago about this on
IRC and he said that the problem could be that exclude_from_all also
does exclude_from_tests which it shouldn't.
Now before I submit a BR against
201 - 277 of 277 matches
Mail list logo
