Alexander Neundorf wrote:
On Monday 16 August 2010, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
Hi,
Once I figured that out I tried to make sure that kdelibs and I think
kdepimlibs stay the only modules which do that.
Some apps that install files to
On Wednesday 18 August 2010, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
On Monday 16 August 2010, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
Hi,
Once I figured that out I tried to make sure that kdelibs and I think
kdepimlibs stay the only modules which do that.
Alexander Neundorf wrote:
On Tuesday 17 August 2010, Andreas Pakulat wrote:
On 16.08.10 23:54:51, Michael Jansen wrote:
And absolutely and totally makes no sense, breaks stuff and is a
surefire symbol for the upcoming apocalypse judging from most comments
i read today.
The apocalypse is
On Tuesday 17 August 2010, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
On Tuesday 17 August 2010, Andreas Pakulat wrote:
On 16.08.10 23:54:51, Michael Jansen wrote:
And absolutely and totally makes no sense, breaks stuff and is a
surefire symbol for the upcoming apocalypse
Andreas Pakulat wrote:
On 16.08.10 00:59:20, Yury G. Kudryashov wrote:
Andreas Pakulat wrote:
On 16.08.10 00:09:41, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
On Sunday 15 August 2010, Yury G. Kudryashov wrote:
Many (all?) KDE modules have the following string in the
Did you contact kitware, or is this a 'your' problem?
No clue. I send the email three times. I guess its in the moderation
queue or spam folder. I am subscribed to the list. But i gave up on that
attempt. I hope someone from kitware is on this list
I thought distro's have switched to lib/
Am 15.08.2010 20:28, schrieb Alexander Neundorf:
On Sunday 15 August 2010, Yury G. Kudryashov wrote:
Hi!
Many (all?) KDE modules have the following string in the beginning of
CMakeLists.txt:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
What do you think about replacing this
On 16.08.10 12:06:35, Michael Jansen wrote:
I thought distro's have switched to lib/ for 64 and 32 bit (depending on
which is the system-arch) and lib32 for the 32-bit compat libs in a
64bit System... Anyway, the above is something you should be taking to
cmake people, obviously lib64
Andreas Pakulat wrote:
On 16.08.10 12:16:41, Yury G. Kudryashov wrote:
Why you don't like the current situation? libktorrent installs
FindKTorrent into prefix/share/apps/cmake/modules. If it is installed,
kdenetwork should find it (if we add CMAKE_PREFIX_PATH -
CMAKE_MODULE_PATH map), else
Andreas Pakulat wrote:
On 16.08.10 14:52:58, Yury G. Kudryashov wrote:
Andreas Pakulat wrote:
On 16.08.10 12:16:41, Yury G. Kudryashov wrote:
Why you don't like the current situation? libktorrent installs
FindKTorrent into prefix/share/apps/cmake/modules. If it is
installed,
Hi,
Le 16/08/2010 12:20, Michael Jansen a écrit :
Because it is the right thing to do. The first line overriding it is
just plain wrong imho.
1. CMAKE_MODULE_PATH is documented in cmake at the same level as
CMAKE_PREFIX_PATH as a variable that changes behaviour. Which means a
user can and
Christophe Giboudeaux wrote:
Hi,
Le 16/08/2010 12:20, Michael Jansen a écrit :
2. KDE installs a ton of useful not kde related FindXYZ*.cmake files
into a path != /usr/share/cmake... . If a non kde project wants to use
it (even a small homegrown project) the user has to set
On Monday 16 of August 2010 14:38:24 Christophe Giboudeaux wrote:
Hi,
Le 16/08/2010 12:20, Michael Jansen a écrit :
Because it is the right thing to do. The first line overriding it is
just plain wrong imho.
1. CMAKE_MODULE_PATH is documented in cmake at the same level as
Am 16.08.2010 14:38, schrieb Christophe Giboudeaux:
Hi,
Le 16/08/2010 12:20, Michael Jansen a écrit :
Because it is the right thing to do. The first line overriding it is
just plain wrong imho.
1. CMAKE_MODULE_PATH is documented in cmake at the same level as
CMAKE_PREFIX_PATH as a
Hi all, Lukas,
On Monday 16 August 2010, Yury G. Kudryashov wrote:
Andreas Pakulat wrote:
On 16.08.10 14:52:58, Yury G. Kudryashov wrote:
Andreas Pakulat wrote:
On 16.08.10 12:16:41, Yury G. Kudryashov wrote:
Why you don't like the current situation? libktorrent installs
Hi,
On Monday 16 August 2010, you wrote:
Am 15.08.2010 20:28, schrieb Alexander Neundorf:
On Sunday 15 August 2010, Yury G. Kudryashov wrote:
Hi!
Many (all?) KDE modules have the following string in the beginning of
CMakeLists.txt:
set(CMAKE_MODULE_PATH
Alexander Neundorf wrote:
Hi all, Lukas,
kdenetwork calls macro_optionally_find_package(KTorrent), and it doesn't
stop processing if it fails to find FindKTorrent.cmake.
This is clearly wrong.
http://websvn.kde.org/trunk/KDE/kdenetwork/CMakeLists.txt?view=log
Uh, so we have that in the
Alexander Neundorf wrote:
Hi,
Once I figured that out I tried to make sure that kdelibs and I think
kdepimlibs stay the only modules which do that.
Some apps that install files to $prefix/share/apps/cmake/modules:
kdebase-workspace-4.5.0
kdegraphics-4.5.0
libktorrent-1.0.2
qjson-0.7.1
Alexander Neundorf wrote:
On Monday 16 August 2010, Yury G. Kudryashov wrote:
Do you have one at hand ?
In qjson sources.
Do you actually have commit access ?
No.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
On Monday 16 August 2010, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
Hi,
Once I figured that out I tried to make sure that kdelibs and I think
kdepimlibs stay the only modules which do that.
Some apps that install files to $prefix/share/apps/cmake/modules:
They are outside
On Monday 16 August 2010 21:09:46 Alexander Neundorf wrote:
I kind of get unwilling to discuss it. So here is my last attempt.
3. If someone develops a small lib he plans to add as a kde dependency
he probably installs it into some non distro prefix so he doesn't need
root rights to
On 16.08.10 23:54:51, Michael Jansen wrote:
On Monday 16 August 2010 21:09:46 Alexander Neundorf wrote:
I kind of get unwilling to discuss it. So here is my last attempt.
3. If someone develops a small lib he plans to add as a kde dependency
he probably installs it into some non distro
Hi!
Many (all?) KDE modules have the following string in the beginning of
CMakeLists.txt:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
What do you think about replacing this string with the following?
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules
${CMAKE_MODULE_PATH})
On 16.08.10 00:09:41, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
On Sunday 15 August 2010, Yury G. Kudryashov wrote:
Many (all?) KDE modules have the following string in the beginning of
CMakeLists.txt:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
What do you
On 16.08.10 00:59:20, Yury G. Kudryashov wrote:
Andreas Pakulat wrote:
On 16.08.10 00:09:41, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
On Sunday 15 August 2010, Yury G. Kudryashov wrote:
Many (all?) KDE modules have the following string in the beginning of
CMakeLists.txt:
Then either specify CMAKE_PREFIX_PATH for fix the FindKTorrent.cmake
module.
Cmake looks for FindKTorrent in CMAKE_MODULE_PATH, not CMAKE_PREFIX_PATH.
Right. So where is the problem? FindKTorrent.cmake should either be part
of cmake itself, part of kdelibs or be part of kdenetwork. Anything
On 16.08.10 01:23:50, Michael Jansen wrote:
Then either specify CMAKE_PREFIX_PATH for fix the FindKTorrent.cmake
module.
Cmake looks for FindKTorrent in CMAKE_MODULE_PATH, not CMAKE_PREFIX_PATH.
Right. So where is the problem? FindKTorrent.cmake should either be part
of cmake itself,
Hi,
On Monday 15 June 2009 20:08:14 Alexander Neundorf wrote:
Some general notes:
-modifying CMAKE_MODULE_PATH is only necessary for installed cmake modules
-every installed cmake module (at least from kdelibs) has to be kept
compatible at least until the end of KDE4,
-so in general, we
On Wednesday 15 July 2009, Christophe Giboudeaux wrote:
Hi,
On Monday 15 June 2009 20:08:14 Alexander Neundorf wrote:
Some general notes:
-modifying CMAKE_MODULE_PATH is only necessary for installed cmake
modules -every installed cmake module (at least from kdelibs) has to be
kept
On Wednesday 15 July 2009 22:59:20 Alexander Neundorf wrote:
I would say so.
At least completely removing set(CMAKE_MODULE_PATH ... ) is a source
incompatible change, since then the using application is required to add
the KDEPIMLIBS_MODULE_DIR to CMAKE_MODULE_PATH, otherwise it doesn't
On Sunday 07 June 2009, Alex Merry wrote:
In KdepimLibsConfig.cmake.in, which is used to generate a file included
when you do find_package(KdepibLibs), the KdepimLibs cmake module directory
(typically the same as the KDE cmake module directory) is added to the
front of CMAKE_MODULE_PATH.
If
On Sunday 07 June 2009 12:23:20 Alex Merry wrote:
On Sunday 07 June 2009 10:13:15 Christophe Giboudeaux wrote:
OK, I thought I'd checked that, but I misread the cmake file. Nonetheless,
I don't think requiring KdepimLibs should prepend the KDE installation
directory to CMAKE_MODULE_PATH -
On Sunday 07 June 2009 10:13:15 Christophe Giboudeaux wrote:
On Sunday 07 June 2009 01:39:21 Alex Merry wrote:
In KdepimLibsConfig.cmake.in, which is used to generate a file included
when you do find_package(KdepibLibs), the KdepimLibs cmake module
directory (typically the same as the KDE
In KdepimLibsConfig.cmake.in, which is used to generate a file included when
you do find_package(KdepibLibs), the KdepimLibs cmake module directory
(typically the same as the KDE cmake module directory) is added to the front
of CMAKE_MODULE_PATH.
If an application/module/whatever sets its
On Sunday 07 June 2009 01:39:21 Alex Merry wrote:
In KdepimLibsConfig.cmake.in, which is used to generate a file included
when you do find_package(KdepibLibs), the KdepimLibs cmake module directory
(typically the same as the KDE cmake module directory) is added to the
front of
On Sunday 07 June 2009 11:13:15 Christophe Giboudeaux wrote:
On Sunday 07 June 2009 01:39:21 Alex Merry wrote:
The correct solution is deleting FindLibKNotificationItem-1.cmake from your
installation dir.
*and your CMakeCache.txt.
There's a quick way to check:
if
36 matches
Mail list logo
