On Friday 10 June 2011, Alexander Neundorf wrote:
Yes, sure, but I'm away from this noon until Sunday evening.
Is this needed already now for 4.7 ?
I was hoping to have some more weeks to give it more testing and finish it.
(it being the Superbuild CMakeLists.txt, which provide builds in
On Friday 06 May 2011, Jeremy Whiting wrote:
You probably didn't see this, so resending directly to you. Don't try to
fix the kdeedu git stuff, it's incomplete, if you want/need to release
kdeedu 4.6.3, release it from svn branch 4.6 rev 1227326, or we can do the
4.6.3 release of kdeedu next
On Saturday 21 May 2011, Eric Hameleers wrote:
The turn of events with KDE 4.7.x is most unfortunate. I noticed an
explosion of source tarballs.
Yes, I started to resemble the git layout in the tarballs, given that I had a
pain in the ass of work to do with reverting the git splitting for the
On Friday 06 May 2011, Jeremy Whiting wrote:
You probably didn't see this, so resending directly to you. Don't try to
fix the kdeedu git stuff, it's incomplete, if you want/need to release
kdeedu 4.6.3, release it from svn branch 4.6 rev 1227326, or we can do the
4.6.3 release of kdeedu next
On Sunday 01 May 2011, Mark Davies wrote:
on kubuntu which doesn't work since it seems to ship the old
CMakeLists.txt from before but the cmake configuration has
Couldn't see your log at that url but presume I'm hitting the same
thing. Below patches fix some of it but still missing a
On Saturday 27 March 2010, Eric Hameleers wrote:
For Slackware's kdebindings package we stopped using parallel make a
long time ago because it did not build reliably that way, but this is
the first time I have to run 'make' twice to finish compilation
successfully (indeed running it a second
On Saturday 27 March 2010, Eric Hameleers wrote:
The kdebindings tarball fails to build with this error:
sip: QDebug is undefined
I get the same when doing a parallel (make -j) build. there is a build
dependency missing, just don't know where to start looking.
Greetings,
Dirk
On Wednesday 24 February 2010, Pavel Heimlich, a.k.a. hajma wrote:
Hi,
since phonon is moved to gitorious, what is the preferred way of
including its support in the nighly builds for cdash.org ?
Should I keep some stable version installed or hack a script to
checkout and build latest git
On Sunday 21 February 2010, Alexander Neundorf wrote:
CMake 2.8.1 RC 3 is ready to try:
http://www.cmake.org/files/v2.8/?C=M;O=D
Please try your projects with it.
I need the attached patch to compile it with fortify checks (check for static
buffer overflows) enabled. the cpu descriptions are
On Thursday 07 January 2010, Alexander Neundorf wrote:
we need 2.6.3 for the shared-desktop-ontologies detection
What ??
Sorry, I assumed this is not a big issue, given that we depend on kdebindings
in kdebase/workspace which only builds against a recent SVN snapshot of the
python sip
On Tuesday 02 December 2008, Alexander Neundorf wrote:
one question to the packagers: do we need the reduced link interface also
for internal shared libraries, e.g. libraries within kdebase, as e.g.
libkonq, or libkopete in kdenetwork ?
in some cases, yes. for me it only matters when we split
On Friday 05 September 2008, Sune Vuorela wrote:
recently, but last I looked, kdepimlibs needs a similar depency trim as
kdelibs got.
You're welcome to post patches for review :)
I just took the easy shortcut and commented out the dependency writing in
kdepimlibs.
Hmm, I don't see what
On Friday 15 August 2008, Alexander Neundorf wrote:
Can you please give it a try and also have a look at the remaining modules
? I'll try kdeedu tomorrow.
Looks good now, I've committed it to ensure that not further things have to be
fixed over time.
Greetings,
Dirk
On Sunday 03 August 2008, Gavin Beatty wrote:
A lot of KDE libraries are being given strange RPATHs. I'm getting
link lines giving this:
installed or uninstalled libraries? for uninstalled that's normal, cmake
reserves some space in the binary to be able to fill in the correct path during
On Friday 25 July 2008, Alexander Neundorf wrote:
Not exactly sure what you mean.
FILE(WRITE APPEND .. ) ?
It looks like the issue was fixed by adding all the generated files to SVN,
which sounds bad to me. Without having gone over all the details discussed in
this thread, isn't there some
On Wednesday 23 July 2008, Alexander Neundorf wrote:
you committed a lot of link fixes in the last days.
Since I don't have the compile-power to check it myself, does everything in
KDE/ now link correctly again ?
everything but kdepim it seems, thats a bigger pain to get right. you can
watch
On Monday 30 June 2008, Alexander Neundorf wrote:
Could you please justify QtNetwork and QtXml here? None of public kio
headers need QtNetwork (actually, QtNetwork is not worth bundling with
anything). QtXml users are kbookmark*.h (internal method) and davjob.h.
In my opinion, they are
On Friday 27 June 2008, Alexander Neundorf wrote:
+macro (KDE4_TARGET_LINK_INTERFACE_LIBRARIES _target _interface_libs)
+ if(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT AND UNIX )# AND NOT APPLE)
+ set_target_properties(${_target} ${_interface_libs})
+
On Tuesday 24 June 2008, Alexander Neundorf wrote:
After you pushed so much, is there now actually any interest in this ?
there is interest, I have a local project which builds (well, doesn't build)
with the experimental link-reduction. I've been wondering though why you're
not committing the
On Monday 26 May 2008, Alexander Neundorf wrote:
This means to make this work for you you have to set the
LINK_INTERFACE_LIBRARIES property for the library targets. This shouldn't
be a problem no matter whether you are using cmake 2.4.x, cmake 2.6.x or
whether this option is enabled or
On Tuesday 06 May 2008, Dirk Mueller wrote:
Thats one solution - another solution is to make it optinally available
now, so that distributions can fix the migration path, and make it a
requirement with KDE 4.2 (or maybe even 4.1).
I forgot to add: Alex do you object to it being available
On Tuesday 29 April 2008, Alexander Neundorf wrote:
Matthias: if we want to keep the option to get it at some point into cmake,
we (you) need to relicense it to BSD. Can you do that ?
can we add a version number and make a formal release of it? I can do the
tarballing and uploading etc if
On Tuesday 06 May 2008, Bill Hoffman wrote:
On behalf of myself, Ken, Brad, Dave, Alex and the rest of the CMake
team, we are pleased to announce that CMake 2.6.0 is available for
download at: http://www.cmake.org/HTML/Download.html
On our behalf: Thanks a lot to all of you for this major new
On Friday 25 April 2008, Brad King wrote:
This is the *exact* same problem as before. The error message is just
more verbose. Now I need to know how to reproduce it. What source tree
do I need to checkout?
I get this from svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs
Please also send
On Thursday 17 April 2008, Alexander Neundorf wrote:
Is there a reason that this has to run at cmake time or would running it
dependency-driven at build time also be ok ?
rcgen can fail if it is too old (e.g. the one from KDE 4.0.x does not work, it
needs the one from trunk).
Greetings,
On Monday 14 April 2008, Brad King wrote:
Okay, it doesn't matter how to reproduce it. The fix is the same.
I've updated to RC9, and got a new problem:
CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE):
file RPATH_CHANGE could not write new
On Monday 14 April 2008, Michael Druing wrote:
Please keep in mind that gold is ELF-only, so it cannot be used to link on
Win32.
Thus, linking KDE with gold must stay an option and shouldn't become the
default (at least until other binary formats are implemented in gold)
I believe that linux
Hi,
I've switched to cmake 2.6 for dashbot
(http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this:
CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE):
file CHRPATH could not write new RPATH /opt/testing/lib to the file
On Monday 14 April 2008, Brad King wrote:
CMake 2.6 comes with an ELF binary parser. It is used to change the
RPATH or RUNPATH of an existing binary before installation. This is
much faster than relinking with a new RPATH as was done by CMake 2.4
(relinking is still used on non-ELF
On Friday 11 April 2008, Thiago Macieira wrote:
Yet GENERIC_LIB_SOVERSION is just set to 4. I miss something,
obviously.
ELF doesn't support that. It should support two numbers: the minimum
version and the current. That is, kdelibs 4.1 is backwards compatible with
4.0; Qt 4.4 is backwards
On Monday 28 January 2008, Allen Winter wrote:
-- Forwarded Message --
Subject: kdelibs/cmake/modules patches
Date: Monday 28 January 2008
From: David Johnson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
At the kde-freebsd team, we have make some simple patches to fix some
On Friday 18 January 2008, [EMAIL PROTECTED] wrote:
I am trying to compile the KDE4 sources from branches/KDE/4.0 and I receive
this message from sandbox: symlink:
/usr/kde/svn/share/doc/HTML/en/sonnet/common (symlink to
/usr/kde/svn/share/doc/HTML/en/common)
I've found and fixed the same
On Sunday 16 December 2007, Alexander Neundorf wrote:
Pros: libs should always have the correct RPATH
why do they need a rpath at all? only because some people have conflicting
libraries installed and forget to set LD_LIBRARY_PATH?
Greetings,
Dirk
On Tuesday 30 October 2007, Ingo Klöcker wrote:
Anyway, I considered doing something similar, i.e. using kdelibs
$PATCH_LEVEL, for KMail each time I forgot to increase KMail's version
number before a new KDE release, but after thinking about the
implications I always dismiss this idea again
On Wednesday, 19. September 2007, David Faure wrote:
-fno-reorder-blocks makes step-by-step debugging very hard, despite what
Dirk and Thiago might say.
it depends on your gcc version of course. there are still many outstanding
issues, but it is a longer term goal to make this work.
I
On Friday, 27. July 2007, Alexander Neundorf wrote:
It may be that there are some more issues with OUTPUT_NAME for libraries.
Even if the fix would go into the next cmake release (2.4.8, but 2.4.7 has
just been released last week), it wouldn't help us, because we can't
require it.
I think
On Friday, 27. July 2007, Alexander Neundorf wrote:
this is the workaround we came up with to get kdepim building again. This
smells like a cmake bug, that it doesn't respect target name here. any
better idea on how to fix it?
You mean export_library_dependencies() ignores the OUTPUT_NAME
On Friday, 6. July 2007, Andreas Pakulat wrote:
Thats not feasible, because some of the sources (though not all) may be
generated (or may be not generated if the generator is missing) and thus
I'd have to copy the generation code into each CMakeLists.txt that wants
to use the sources.
Ehm,
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.
Dirk
___
Kde-buildsystem mailing list
On Thursday, 21. June 2007, Thiago Macieira wrote:
1. phonon which uses Q_DECL_EXPORT as export macro
Can't phonon be fixed to not use broken Qt defines (are they documented at
all. Why use undocumented API) ?
It's much easier and even probably better to define KDE_EXPORT as
Q_DECL_EXPORT
On Friday, 18. May 2007, David Faure wrote:
Hmm, shouldn't emitted.insert(/lib); be added to that list too?
Someone in the koffice irc channel just reported seeing -L/lib in his link
What about /opt/testing/lib, /opt/kde4/lib, /usr/local/lib ?
Dirk
On Thursday, 8. March 2007, Alexander Neundorf wrote:
Do you know when SUSE 10.3 and kUbuntu 7.04 Feisty Fawn wil be released and
which versions they will ship ?
10.3 will ship 2.4.6 at least. But its not that much of an issue anyways,
since we have a full set of KDE:KDE4 rpms including build
On Thursday, 22. February 2007 10:51, Thiago Macieira wrote:
What were those linking errors? Were they justified?
In some cases, they are, like for example virtual inline functions. In some
other cases, they were not (missing #include caused gcc to interpret type
attributes as instantiation
On Thursday, 22. February 2007 11:17, Dirk Mueller wrote:
Is there some (undocumented) way of getting rid of all this fancy stuff
that nobody needs?
To be more precise:
I don't want it to output progress information when it might not have done
anything heavy. for example the Built target
Hi,
coolo and I are wondering how to add a custom target, that when invoked,
builds a lot of generated sources (consisting of a couple of custom compile
defines and an include statement) in parallel (up to the usual make -j
parallelism level) and does not link them together (because linking
On Wednesday 25 October 2006 19:17, David Faure wrote:
Linking CXX shared library ../lib/libkpresenterprivate.so
[ 99%] Built target kpresenterprivate
make: *** [all] Error 2
What's that? Ctrl-C ? ;)
No, incorrect grepping. the problem is that moc generation seems to randomly
fail, I
On Wednesday 18 October 2006 07:50, Thiago Macieira wrote:
Well, then we need to port -Wl,--as-needed over to CMake. it would also
help in general, therefore being a good thing.
Can you explain your reasoning?
The reason is that the -Wl,--as-needed feature was lost by the switch to
CMake,
On Tuesday, 17. October 2006 15:32, David Faure wrote:
But the practical problem is that on Linux it all links just fine via
kdecore, so the developers will never remember to add such explicit links,
since it works for them (tm). So the guys doing Mac OS (and maybe
Windows) porting will keep
Hi,
it seems cmake misses python 2.5 support - something like the patch below
should do I guess.. can this be added to CMake? its not in 2.4 CVS branch so
far.
Thanks,
Dirk
--- Modules/FindPythonLibs.cmake
+++ Modules/FindPythonLibs.cmake
@@ -12,8 +12,10 @@
IF(WIN32)
On Tuesday, 26. September 2006 20:02, Dirk Mueller wrote:
it seems cmake misses python 2.5 support - something like the patch below
should do I guess.. can this be added to CMake? its not in 2.4 CVS branch
so far.
a bit more complete patch.
--- Modules/FindPythonInterp.cmake
+++ Modules
On Wednesday, 13. September 2006 15:11, William A. Hoffman wrote:
However, there seems to be enough of an outcry here, that I suppose we
should reconsider. Having an option that defaults to off could be done.
Distributors are probably going to or already ship cmake, so you should make
their
Hi,
I've noticed that cmake contains deep copies of various 3rd party libraries,
including really old versions of libcurl and zlib. I created a hackish patch
to make it build against the system version of those libraries.
Dirk
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -72,20 +72,19 @@
On Thursday 31 August 2006 00:09, Michael Biebl wrote:
Recently the build system of kdesvn [1], a KDE3 application, was
switched from auto* to cmake.
Unfortunately the build fails for me (running a Debian unstable box
with latest KDE and qt3).
I wouldn't recommend to use cmake with kdesvn. I
On Wednesday 30 August 2006 10:14, Stephan Kulow wrote:
other target that come close to A? That is pretty much not what you expect
to happen - anyway I can't test atm, I'll commit if it works.
Since my compile dashboard stumbles over it all the time (it builds from clean
sources with -j12),
On Monday 17 July 2006 20:09, Matt Broadstone wrote:
Hi, I submitted a patch to kfm-devel to convert khtml to use
libtool-esque convenience libraries yesterday, and wanted to move the
discussion over here as it seems more appropriate.
What is the reason for that?
Dirk
On Tuesday 27 June 2006 17:37, Alexander Neundorf wrote:
But does that mean to insert the BSD copyright header in every tiny cmake
file ?
Well, in every file somebody else could copy over. another possibility would
be to add a special exception clause, like autoconf does:
# As a special
Hi,
Before its too late: has anyone ever thought about the licensing of the cmake
module files? I think we should re-license them as loosely as possible
(X11/MIT license), so that other projects can just copypaste the code
freely.
Any opinions?
Dirk
On Tuesday, 23. May 2006 23:37, Adriaan de Groot wrote:
LD_LIBRARY_PATH=/tmp/bu/lib/./:/usr/local/lib:/tmp/bu/lib/.:/usr/lib${LD_LI
BRARY_PATH+: $LD_LIBRARY_PATH} /tmp/bu/bin/dcopidl2cpp $@
And where does :/usr/lib come from?
Dirk
___
On Friday, 19. May 2006 09:18, Stephan Kulow wrote:
I don't think we want to mess with dcop's dependencies at this point.
Just hardcore #include ../../ the files or copypaste the code. its just 5-10
lines anyway.
Dirk
___
Kde-buildsystem mailing
On Thursday, 18. May 2006 22:36, Stephan Kulow wrote:
file somewhere below CMakeFiles, but I have no idea how to fix this
correctly.
an easy workaround would be to fix dcopidl2cpp to use KSaveFile instead of
open+truncate for writing its output.
Dirk
On Monday, 15. May 2006 11:49, David Faure wrote:
Please note that the way KDEDIR/KDEDIRS works for all other purposes in KDE
is: * if KDEDIRS is set then it is used, and KDEDIR is ignored
* otherwise (KDEDIRS not set) KDEDIR is used
KDEDIR should be always ignored.
Dirk
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, as it processes all the output.
If it doesn't print what
On Saturday, 22. April 2006 22:17, Alexander Neundorf wrote:
It will be required for compiling kdelibs from trunk in a few days.
Could you tell me why exactly, please? Is there some new feature in cmake
2.4.0 that requires the version update?
I'm just asking because it took me more than 3
On Sunday, 23. April 2006 21:36, David Faure wrote:
#if HAVE_ARTS
They were defined to either 0 or 1 in KDE3. That's why there wasn't a
problem.
In general, no, HAVE_FOO was undefined or set to 1. That's how most
configure checks did it, at least, but maybe HAVE_ARTS was different.
On Thursday, 13. April 2006 23:03, Albert Astals Cid wrote:
imagine you fix one header in kdelibs and do make install, ALL headers are
installed and automatically all your programs want to start rebuilding
because they think the header changed.
this is not an unsermake feature. you could
On Wednesday, 12. April 2006 12:02, David Faure wrote:
Since commands are case insensitive, can --help be fixed to be case
insensitive as well? Thanks.
It is case insensitive, if your operating system is ;)
--
Dirk//\
___
Kde-buildsystem mailing
On Wednesday, 12. April 2006 18:38, David Faure wrote:
One difference is the lack of -DPIC, but could this matter? This is too
lowlevel for me, let's see what kde-buildsystem has to say ;)
We use -fno-common because we don't want common symbols. Why you have common
symbols with unsermake is a
On Wednesday, 12. April 2006 20:24, Allen Winter wrote:
But Dirk, with -fno-common I have no way of linking this yacc/lex generated
code.
No, you need to fix your symbol conflict instead.
I do have hopes (if Cornelius' kode stuff can support it) of replacing
libkholidays with a brand new,
Hi,
I fixed the unsermake errors in kdelibs locally and ran
unsermake --compile-jobs=500 / make -j500 with cmake (over a big icecream
cluster). Enjoy.
unsermake:
real32m55.389s
user15m29.590s
sys 9m20.351s
cmake:
real7m48.456s
user5m31.316s
sys 3m3.135s
--
On Wednesday, 22. March 2006 18:42, Alexander Neundorf wrote:
Dirk, why is this required for you ?
It really shouldn't.
I don't see how, there are no rpaths anywhere, and it only finds the installed
KDE 3 libraries (because they have the same SONAME, which is a bug on its own
I'm currently
On Thursday, 23. March 2006 20:17, William A. Hoffman wrote:
KDE4_BUILD_TESTS:BOOL=ON
To both my nightly and continuous builds so that the tests will be run as
well.
Most of the tests should fail though as they require a running system, which
you're unlikely to have on a dashboard
On Friday, 17. March 2006 19:09, Laurent Montel wrote:
find_package(JPEG)
if (JPEG_FOUND)
add_subdirectory(foo)
else (JPEG_FOUND)
message(STATUS To compile foo install the JPEG library)
endif (JPEG_FOUND)
Ok I will use it.
And its automatically guaranteed to run after
72 matches
Mail list logo
