On Thursday 29 November 2012, Kevin Ottens wrote:
On Thursday 29 November 2012 08:37:15 Alexander Neundorf wrote:
On Thursday 29 November 2012, Kevin Ottens wrote:
Hello,
We currently have kde4_add_plugin calls in our cmake files, they can be
replaced with:
add_library(foo
On Thursday 29 November 2012 09:08:05 Alexander Neundorf wrote:
In KDE4 we do it this way because we did it this way in KDE3. ;-)
Personally I don't care much whether plugins have a lib prefix or not. Not
having the lib prefix can be interpreted as a hint that this file is not
a normal shared
On Thursday 29 November 2012 09:36:33 Alexander Neundorf wrote:
On Thursday 29 November 2012, David Faure wrote:
On Thursday 29 November 2012 09:08:05 Alexander Neundorf wrote:
In KDE4 we do it this way because we did it this way in KDE3. ;-)
Personally I don't care much whether plugins
Stephen Kelly steveire at gmail.com writes:
So what can we now do in kde buildsystems to modernize them and make them
ready for KF5?
Alex, can you comment on this?
http://article.gmane.org/gmane.comp.kde.devel.buildsystem/7545/match=required
___
Stephen Kelly wrote:
Stephen Kelly steveire at gmail.com writes:
So what can we now do in kde buildsystems to modernize them and make them
ready for KF5?
Alex, can you comment on this?
http://article.gmane.org/gmane.comp.kde.devel.buildsystem/7545/match=required
I have this patch to
On Tuesday 06 November 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Friday 26 October 2012, Alexander Neundorf wrote:
On Thursday 18 October 2012, Alexander Neundorf wrote:
Hi,
in kdelibs we require since more than 2 years cmake .2.6.4, since then
many improvements and
Am 29.11.2012 09:36, schrieb Alexander Neundorf:
I just had a look at the gimp plugin dir, those seem to be
executables
(no prefix, no suffix, and they say compose is a GIMP
plug-in and must be run by GIMP to be used when executed.
Unusual :)
At least that makes the lookup
Alexander Neundorf wrote:
On Tuesday 06 November 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Friday 26 October 2012, Alexander Neundorf wrote:
On Thursday 18 October 2012, Alexander Neundorf wrote:
Hi,
in kdelibs we require since more than 2 years cmake .2.6.4, since
Hi all,
It seems that following a recent CMake build from latest sources that
the configure time for Calligra has severely regressed.
It now takes in excess of 1 hour to complete the configure process,
which is disrupting the operation of build.kde.org.
Timestamped output:
14:45:29 -- cstester
Ben Cooksley wrote:
Hi all,
It seems that following a recent CMake build from latest sources that
the configure time for Calligra has severely regressed.
It now takes in excess of 1 hour to complete the configure process,
which is disrupting the operation of build.kde.org.
Timestamped
Stephen Kelly wrote:
Ben Cooksley wrote:
Hi all,
It seems that following a recent CMake build from latest sources that
the configure time for Calligra has severely regressed.
It now takes in excess of 1 hour to complete the configure process,
which is disrupting the operation of
Hi,
could somebody have a look on my cmake-code I inserted in KDevelop-PG-Qt for
transition from 1.0.0 to 1.0.1? We want to create a 1.0.1 bugfix release (it
is compatible with 1.0.0) soon. It seems to work, but I’m not a cmake
expert, maybe it is not the correct way to implement those checks:
Hi,
assuming you have kdelibs development stuff installed you could look
at MacroWriteBasicCMakeVersionFile.cmake and
BasicFindPackageVersion.cmake.in for inspiration.
Unless you want to support CMake 2.6, you should probably use
VERSION_LESS Co for the actual checks.
I also don't think you
13 matches
Mail list logo
