Re: RFC: Release Management Going Forward
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 old-style KDE modules or in the future maybe even an all-in-one build using CMakes ExternalProject feature). In git there is a repository superbuild now, but it's not yet done. Alex, can I make use of that now? I would like to tag RC1 tomorrow. For which modules is this right now ? kdesupport, kdegraphics, more ? kdeedu as well, kde-baseapps and kde-runtime. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: KDE 4.6.3 tarballs (try#1 part1) uploaded
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 week once Nicolas has got the svn-git migration issues fixed. I don't think it's worth delaying the rest of kde for our mistake in kdeedu. Hi Jeremy, what should I do for kdeedu 4.6.4 now? Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
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 4.6 branch releases. I'll attach them for reference, but those scripts are ugly. I'm not aware of a better solution though, unless we use git submodules or maintain those scripts in the SVN. Dirk, are instructions available on how to re-assemble sources back to the original set? Or else, are instructions available on how to compile the bigger all-comprising packages where the separated applications and libraries are included again, like was the case all the time up to 4.7? I don't have those available at the moment. I used scripts to reassemble them to original tarballs, but I haven't properly pushed this into KDE git back yet. Can I get the opinion of the other distro packagers as well please? Personally I was much more happy with the previous module-based layout, though I can cope reasonable with the current situation as well. Any other opinon? Eric, thanks for sharing your thoughts. I hope we can find a solution that suits your needs as well. If all else fails, I'm willing to give maintaining those reassembling-scripts a try, but it is an extra effort, given that the tarballs are much different from how developers build it, so regressions in the build system are likely. Greetings, Dirk setup-kdeedu.sh Description: application/shellscript setup-kdegraphics.sh Description: application/shellscript ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: KDE 4.6.3 tarballs (try#1 part1) uploaded
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 week once Nicolas has got the svn-git migration issues fixed. I don't think it's worth delaying the rest of kde for our mistake in kdeedu. Hi Jeremy, thanks for the input, I've used the svn branch for the 4.6.3 tarball now and uploaded this new version: 0ac011016550114c1eb8347061e2cbc5 kdeedu-4.6.3.tar.bz2 if a compile-test passes, Sebas and I will announce 4.6.3 tomorrow (well, later today) morning. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE 4.6.3 tarballs (try#1 part1) uploaded
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 FindLibKdeEdu.cmake for parley and kalgebra and something for Avogadro in kalzium. I seem to be stuck on those problems as well. I've tried for the last few hours to figure out how to easily make those git modules build when libkdeedu is in the same tarball, but it seems the whole infrastructure for that is missing now. Anyone who can help with that? Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE 4.4.2 tarballs (try #1) uploaded
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 time works, as suggested in the previous post). This updated package fixes the issue for me: 50ac156078e5069b8400033653b59382 kdebindings-4.4.2.tar.bz2 Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE 4.4.2 tarballs (try #1) uploaded
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: phonon in the Nightly builds
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 prior to running the Nightlys-2.6.2 script? My recommendation would be to keep the last stable version installed - thats the version KDE should compile against (or whatever version we decide to use as a minimum requirement). Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: [CMake] CMake 2.8.1 RC 3 is ready to try
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 simply longer than the
allocated buffer, and the tar part is overwriting two fields with one command.
Greetings,
Dirk
--- Source/kwsys/SystemInformation.cxx
+++ Source/kwsys/SystemInformation.cxx
@@ -152,7 +152,7 @@
public:
#define VENDOR_STRING_LENGTH(12 + 1)
-#define CHIPNAME_STRING_LENGTH(48 + 1)
+#define CHIPNAME_STRING_LENGTH(70 + 1)
#define SERIALNUMBER_STRING_LENGTH (29 + 1)
typedef struct tagID
--- Utilities/cmtar/encode.c
+++ Utilities/cmtar/encode.c
@@ -32,7 +32,10 @@
int i, sum = 0;
if (t-options TAR_GNU)
-strncpy(t-th_buf.magic, ustar , 8);
+ {
+strncpy(t-th_buf.version, , TVERSLEN);
+strncpy(t-th_buf.magic, ustar, TMAGLEN);
+ }
else
{
strncpy(t-th_buf.version, TVERSION, TVERSLEN);
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE/kdelibs/cmake/modules
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 generator. But okay, I learn that there are different standards :) SDI is just a simple file, this surely can't be the reason for increasing the required version of cmake. it wasn't found with 2.6.2, it seems people just upgraded instead of bothering. Thank you for fixing it though, I'll include this in the RC1 tarball. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Reduced link interface - now for real
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 it into differences packages,because then it makes a real difference in dependencies. so for prominent libs where other modules depend on yes, for something like libkopete no. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [PATCH] really reduced link interface
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 that fixes. it will then also not export the link_interface_libraries. Can you be more specific in the bloat that kdepimlibs dependencies introduce? On top of that, I just needed a bit of patching to kdeplasma-addons and kdepim and a few other places. .. which you just noticed here. I think adding QTCORE_LIBRARY and similar to a lot of places indicates that this has been an overly greedy cut of of library dependencies. there is essentially no useful KDE library that does not depend on QtCore. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [PATCH] really reduced link interface
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH with multiple empty paths (e.g., ::::::::)
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 installation without relinking (which is somewhat slower). if it breaks your scripts (it breaks mine), -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON helps. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Help Rewriting kdepim/akonadi/agents/nie/CMakeLists.txt
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 way to let cmake generate those files during build time? Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: status of reduced link interface ?
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 the status at http://developer.kde.org/~dirk/dashboard If so, what do you think about removing the option and making the reduced linking the default in trunk next monday ? Thats what I wanted to propose as well, you just wrote the email faster. :) And, what do you think about 4.1 branch ? It would be nice if we would have it there too, as soon as possible. It is possible to backport the changes, but there might be new link failures in unusual configurations.. tricky to get right in that short amount of time. Oh, I just noticed 4.1.0 has been tagged yesterday. So if we do this for 4.1.1, we'll kind of break compatibility between 4.1.0 and 4.1.1. we only break source compatibility, not binary compatibility. so its possible to do that for 4.1.1. Which part do you want to have backported? the link line fixes or the actual dependency reduction patch (with the LINK_INTERFACE_LIBS)? P.S. did I miss a reminder email 4.1.0 will be tagged tomorrow or something like this ? This would have been nice. Or is the average developer now expected to subscribe to kde-releaseteam ? No, but knowing about freezes. There was no announcement on kde-cvs-announce this time because we often got complains about the mail flood. Well, seems like it is necessary after all. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs
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 not good enough reason to pull QtXml. Application can specify it manually. However, it is true that there will be relatively many linking failures due to missing QtXml. That's the justification. Avoiding too much breakage. I don't expect that much breakage from it, but we can do that it in multiple passes, it doesn't have to be right on the first try. I can prepare a patch with all these changes if you agree with them. Yes, please. Dirk, comments ? Suggestions sound good to me. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs
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})
+ endif(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT AND UNIX)# AND NOT
APPLE) +endmacro (KDE4_TARGET_LINK_INTERFACE_LIBRARIES)
Hmm, I don't like that.
If we do it, I'd prefer that we do it only this new way, i.e. all KDE
builds will use the new style.
I don't get what you mean here.
Adding the macro to KDE4Macros.cmake means that we have to maintain it for
all of KDE 4.x.
there is not an awful lot to maintain with this macro.. it just encapsulates
the experimental ifdef.
I'd prefer to see it as a temporary hack during the transition.
if we care that much about not breaking the build for 3rd parties, then we
have to keep the building type configurable.. and that even without recompiling
kdelibs (which is not possible at the moment). e.g. if you run into a linking
issue due to LINK_INTERFACE_LIBRARIES, a -DKDE4_COMPAT_LINK_INTERFACE=ON (or
something like that) must restore the old behaviour without having to
recompile underlying modules.
the only way to implement that would be to write both dependency styles to the
Dependencies.cmake file, and it select the right variant via some if() magic -
and thats exactly where such a macro that hides all the uglyness helps.
How about prefixing it with an underscore to make clear it's no public
macro ?
fine with me as well.
And additionally moving it out of KDE4Macros.cmake into
kdelibs/CMakeLists.txt, so it stays within kdelibs. We might need to copy
it ti kdepimlibs. Is this actually important also for libraries in other
modules ?
yes, I use it for processui/core in ksysguard and other libraries in
kdebase/apps/lib and kdebase/workspace/libs. all other modules also contain
libraries (e.g. kdegraphics/libs) etc.
I assume however that modules outside kdelibs,kdebase only need minimal
patching, but I'm not there yet.
Or, instead of using a macro, how about this:
if(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT AND UNIX )
set(DISABLE )
else(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT AND UNIX )
set(DISABLE DISABLED_PROPERTY_)
endif(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT AND UNIX )
and then do
set_target_properties(khtml PROPERTIES VERSION
${KDE_NON_GENERIC_LIB_VERSION} SOVERSION ${KDE_NON_GENERIC_LIB_SOVERSION}
${DISABLE}LINK_INTERFACE_LIBRARIES
kparts;kjs;kio;kdeui;kdecore)
So if the option is enabled, DISABLE is empty and the correct property is
set, otherwise a useless property is set.
Still this should be done only for the transition period I'd say.
I think thats even harder to understand than a custom kde4_ macro, but it
would also be fine with me.
How long does the transition period last in your opinion? until KDE 4.1
release or KDE 4.2 release?
Greetings,
Dirk
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs
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 kdelibs link line fixes to trunk? they can't hurt as long as experimental link reduction is not enabled, does it? The release is in more or less one month, so it is really getting late... I need your feedback and work to get this integrated into svn. I have a couple of patches, let me clean them up and post them later today (really need to get something done elsewhere at the moment, sorry). Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs
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 disabled. If it is disabled, the property will be set but it will be completely ignored. If it works for you, and also Dirk agrees, and also the release team agrees, I'd enable this always under UNIX (not APPLE). Dirk, Sune, Modestas, any comments or interest in this ? All fine for me, go ahead. I can help with fixing/testing it somewhen end of next week. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs
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 optionally already now? Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
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 nobody else wants. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMake 2.6.0 available for download
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 release!! Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
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 me the CMakeCache.txt from the build tree, plus the cmake/automoc/cmake_install.cmake file, and /opt/kde-41/bin/kde4automoc, and the kde4automoc from the build tree. sure, will be in another personal email. you can also reach me via irc or jabber ([EMAIL PROTECTED]) to make me send you additional debug or point me where to look at things. Thank you for your help. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: kdepim/akonadi/agents/nepomuk_contact_feeder/CMakeLists.txt
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, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
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 RPATH: /opt/kde-41/lib to the file: /opt/kde-41/bin/kde4automoc No valid ELF RPATH entry exists in the file; Call Stack (most recent call first): cmake/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:45 (INCLUDE) that is a new bug we have due to our strange rpath related settings (Alex?)? I'm working around this install error with -DCMAKE_SKIP_RPATH=ON for now. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: The gold linker and KDE
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 distributions will switch to the gold linker or provide it optionally and those problems in underlying packages will be fixed then over time. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
problem with cmake 2.6RC6 and KDE 4
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 /var/tmp/kdelibs-796689-build/opt/testing/bin/kde4automoc: No valid ELF RPATH entry exists in the file; how can I get rid of that? this is KDE trunk, configured with: cmake -DKDE4_BUILD_TESTS=ON -DCMAKE_INSTALL_PREFIX=/opt/testing -DCMAKE_BUILD_TYPE=release a slightly related and annoying note: for some projects (e.g. strigi) it writes an empty rpath into the binaries during installation instead of removing the rpath. that breaks certain checks and is dangerous, as some ld.so versions interpret empty as current directory which allows trivially to hijack applications by e.g. adding a hacked libc.so.6 to the start up directory. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
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 systems). That much I know. why it triest to put a rpath into a binary that doesn't have an rpath (why?) is the problem I'm stumbling over.. I'd love to debug it if I'd just know how. Add -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON to switch back to the relinking approach. added, will test. Ugh, I didn't know that about ELF linkers. IMO that's pretty stupid because users can always put '.' in the RPATH if they want that behavior. it is consistent with $PATH expansion though (e.g. trailing ':' also produces this effect). Do you know any safe way to remove the RPATH entry without changing the binary size? Is it safe to just swap the DT_RPATH or DT_RUNPATH entry to the end of the dynamic section and replace it with DT_NULL (and replace the rpath string with all 0 bytes)? that sounds like a possible solution. I don't know enough about ELF details to judge if that has any side effects. Sorry for not reporting it to the cmake bugreporter so far, I'm not sure if this is a kde specific system (as I know that we have quite some rpath related magic everywhere), thats why I didn't report it. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: How to use PROPERTIES VERSION and SOVERSION?
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 compatible with 4.0 as well (including all in-between). Of course it does support that. It is called symbol versioning. It is quite a lot of manual maintenance overhead, and quite difficult to do for C++ (because it is hard to predict the mangled name). You'd need a good tool for that. I don't know one. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: kdelibs/cmake/modules patches
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 linkage errors, that will sometimes link to KDE3/Qt3 instead of KDE4/Qt4. These patches work on FreeBSD, and have been tested on Linux (Arch) as well. We would like to get these into the upstream. Can you look these over and check their appropriateness? If okay I can check them into 4.0 and trunk. Looks correct to me, please commit. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Sandbox issues with branches/KDE/4.0
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 error a while ago in trunk/. change is backported now. Please do not use HTML messages when posting to a mailing list. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [PATCH] builds libs by default with full RPATH
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Bug reporting for KDE 4
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 very quickly. One reason against this is that the version string would reflect the version of kdelibs the app was compiled against which might have little to do with the actual version of the app. Granted this is mainly a problem for people trying out the bleeding-edge svn version of an application compiled against the latest stable release of kdelibs. I agree that this is a problem. How about we put some thought into the discussion. One possibility would be to add cmake magic to read a file in the modules top directory if it exists, and to define a module version then (otherwise default to the KDE platform version). The advantage would be: a) release tarballs can ship such a file, defining the version to use b) distributions using stable branches can use this file to declare specifically which version of the module they took c) users from svn don't have inconvenience of e.g. having to create this file via svnversion manually. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Debug buildtype broken
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 however would not like to see an option for -g3 - we're not using that much macros to justify the tremendous overhead. However the point of having -O2 in the default flags is that -O2 gives better warnings than -O0. Yes, this is the main point. It also gives you a variable and code layout that is similar to the release builds that are part of a distribution. I can't stress this point enough because I'm often debugging issues that go away with -O0 and are therefore claimed to be compiler bugs, even though the bug is in the actual source, just that optimisation uncovered it. 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. it is just too complex, especially if you have to step through hundreds of inline expansions of trivial accessors to get somewhere. therefore, the default debug build should be a reasonable optimized build with good backtraces. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: KDE/kdepimlibs
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 this means we cannot have + in library names. can you post the patch to cmake or point me to the place where to find it? I think it would be okay to let distributions patch their cmake installation with it, as it is a pretty genuine and annoying bug. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: KDE/kdepimlibs
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 target property ? Yes, thats how it looks like to me. I'll check tomorrow. Thanks :) Maybe we could keep the name without + ? Talk to Marc Mutz about that :) Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
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, parse error here. you only have to SET a variable and use that one in other places. Unless I'm missing something. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
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 Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 (similarly for KDE_IMPORT). I disagree. coupling them with Qt deserves no purpose (there might be distros out there that compile Qt without hidden visibility for compatibility but still don't want a slow KDE). Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: required CMake version is still 2.4.3
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 dependencies for older distributions. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: how to build generated sources in parallel with out linking them together?
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 names). Overall the idea of building them in-place has to be scratched, #include .. vs doesn't have the right meaning. I've written a 6 line gnu makefile that does the same thing and added it to the dashboard. (its not yet causing an error though because I first want to make sure that kdelibs passes before enabling it). Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: disable progressinfo?
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 output: most of the time there is just nothing done, so you're causing make to fork() and exec cmake, while it could have just skipped evaluation of the target rules (which would probably be faster, and not cause konsole to scroll unnecessarily). Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
how to build generated sources in parallel with out linking them together?
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 does not work). any idea how to do that with cmake? we've tried to define sources and add_executable (which however links and does not work), and we've tried to add a custom target that depends on the object files (which does not work because the object fiels are not compiled) and we've tried checkcxxsourcecompiles (which does not work because it is not done parallel). So... ? Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [Kde-dashboard] Failed trunk/koffice r599064
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 often see stuff like make[2]: *** No rule to make target `khexedit/lib/kcolumnsview.moc', needed by `khexedit/lib/CMakeFiles/testkhexeditcommon.dir/kcolumnsview.o'. While after the next rebuild it succeeds again. it seems our buildsystem is broken. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDELibsDependencies.cmake problem (Re: KDE/kdebase/runtime/kioslave/smtp)
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, as was a lot of other buildsystem features which we had before. I am building KDE with --as-needed and sometimes the build fails because indirect dependencies aren't found during link. Well, that can only be a bug. But given that I don't know where it fails, I can only guess. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDELibsDependencies.cmake problem (Re: KDE/kdebase/runtime/kioslave/smtp)
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 having to fix up CMakeLists to add explicit linking afterwards - which breaks the idea of a cross-platform build system IMHO; we should ensure that when it works somewhere it works everywhere as much as possible. Well, then we need to port -Wl,--as-needed over to CMake. it would also help in general, therefore being a good thing. the problem is only visible because kdecore doesn't use QtNetwork. That is probably going to change over time, so the issue goes away. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
python 2.5 support in cmake
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)
FIND_LIBRARY(PYTHON_DEBUG_LIBRARY
-NAMES python24_d python23_d python22_d python21_d python20_d python
+NAMES python25_d python24_d python23_d python22_d python21_d python20_d python
PATHS
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]/libs/Debug
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]/libs/Debug
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]/libs/Debug
@@ -32,7 +34,8 @@
ENDIF(WIN32)
FIND_LIBRARY(PYTHON_LIBRARY
- NAMES python24 python2.4
+ NAMES python25 python25.
+python24 python2.4
python23 python2.3
python22 python2.2
python21 python2.1
@@ -41,6 +44,7 @@
python15 python1.5
PATHS
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.2\\InstallPath]/libs
@@ -50,6 +54,7 @@
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\1.5\\InstallPath]/libs
PATH_SUFFIXES
+python2.5/config
python2.4/config
python2.3/config
python2.2/config
@@ -67,7 +72,7 @@
SET(PYTHON_FRAMEWORK_INCLUDES)
IF(Python_FRAMEWORKS)
IF(NOT PYTHON_INCLUDE_PATH)
-FOREACH(version 2.4 2.3 2.2 2.1 2.0 1.6 1.5)
+FOREACH(version 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5)
FOREACH(dir ${Python_FRAMEWORKS})
SET(PYTHON_FRAMEWORK_INCLUDES ${PYTHON_FRAMEWORK_INCLUDES}
${dir}/Versions/${version}/include/python${version})
@@ -81,6 +86,7 @@
PATHS
${PYTHON_FRAMEWORK_INCLUDES}
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]/include
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]/include
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]/include
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.2\\InstallPath]/include
@@ -90,6 +96,7 @@
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\1.5\\InstallPath]/include
PATH_SUFFIXES
+python2.5
python2.4
python2.3
python2.2
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: python 2.5 support in cmake
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/FindPythonInterp.cmake
@@ -7,8 +7,9 @@
#
FIND_PROGRAM(PYTHON_EXECUTABLE
- NAMES python2.4 python2.3 python2.2 python2.1 python2.0 python1.6 python1.5 python
+ NAMES python2.5 python2.4 python2.3 python2.2 python2.1 python2.0 python1.6 python1.5 python
PATHS
+ [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.2\\InstallPath]
--- Modules/FindPythonLibs.cmake
+++ Modules/FindPythonLibs.cmake
@@ -12,8 +12,10 @@
IF(WIN32)
FIND_LIBRARY(PYTHON_DEBUG_LIBRARY
-NAMES python24_d python23_d python22_d python21_d python20_d python
+NAMES python25_d python24_d python23_d python22_d python21_d python20_d python
PATHS
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]/libs/Debug
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]/libs/Debug
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]/libs/Debug
@@ -32,7 +34,8 @@
ENDIF(WIN32)
FIND_LIBRARY(PYTHON_LIBRARY
- NAMES python24 python2.4
+ NAMES python25 python2.5
+python24 python2.4
python23 python2.3
python22 python2.2
python21 python2.1
@@ -41,6 +44,7 @@
python15 python1.5
PATHS
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]/libs
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.2\\InstallPath]/libs
@@ -50,6 +54,7 @@
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\1.5\\InstallPath]/libs
PATH_SUFFIXES
+python2.5/config
python2.4/config
python2.3/config
python2.2/config
@@ -67,7 +72,7 @@
SET(PYTHON_FRAMEWORK_INCLUDES)
IF(Python_FRAMEWORKS)
IF(NOT PYTHON_INCLUDE_PATH)
-FOREACH(version 2.4 2.3 2.2 2.1 2.0 1.6 1.5)
+FOREACH(version 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5)
FOREACH(dir ${Python_FRAMEWORKS})
SET(PYTHON_FRAMEWORK_INCLUDES ${PYTHON_FRAMEWORK_INCLUDES}
${dir}/Versions/${version}/include/python${version})
@@ -81,6 +86,7 @@
PATHS
${PYTHON_FRAMEWORK_INCLUDES}
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]/include
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]/include
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]/include
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.2\\InstallPath]/include
@@ -90,6 +96,7 @@
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\1.5\\InstallPath]/include
PATH_SUFFIXES
+python2.5
python2.4
python2.3
python2.2
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: build cmake against system libs
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 job easier, because they always want to use system libraries to reduce code bloat. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
build cmake against system libs
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 @@
#-
# Build zlib library for Curl, CMake, and CTest.
-SUBDIRS(Utilities/cmzlib)
SET(CMAKE_ZLIB_INCLUDES
- ${CMAKE_CURRENT_BINARY_DIR}/Utilities
- )
-SET(CMAKE_ZLIB_LIBRARIES cmzlib)
+ /usr/include
+)
+SET(CMAKE_ZLIB_LIBRARIES z)
SET(CURL_SPECIAL_LIBZ ${CMAKE_ZLIB_LIBRARIES})
SET(CURL_SPECIAL_LIBZ_INCLUDES ${CMAKE_ZLIB_INCLUDES})
-SET(CURL_SPECIAL_ZLIB_H cmzlib/zlib.h)
+SET(CURL_SPECIAL_ZLIB_H zlib.h)
#-
# Build Curl library for CTest.
-SUBDIRS(Utilities/cmcurl)
-SET(CMAKE_CURL_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/Utilities)
-SET(CMAKE_CURL_LIBRARIES cmcurl)
+#SUBDIRS(Utilities/cmcurl)
+#SET(CMAKE_CURL_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/Utilities)
+SET(CMAKE_CURL_LIBRARIES curl)
#-
# Build Curl library for CTest.
@@ -95,12 +94,12 @@
#-
# Build expat library for CMake and CTest.
-SUBDIRS(Utilities/cmexpat)
-SET(CMAKE_EXPAT_INCLUDES
- ${CMAKE_CURRENT_BINARY_DIR}/Utilities
- ${CMAKE_CURRENT_BINARY_DIR}/Utilities/cmexpat
- )
-SET(CMAKE_EXPAT_LIBRARIES cmexpat)
+#SUBDIRS(Utilities/cmexpat)
+SET(CMAKE_EXPAT_INCLUDES /usr/include)
+# ${CMAKE_CURRENT_BINARY_DIR}/Utilities
+# ${CMAKE_CURRENT_BINARY_DIR}/Utilities/cmexpat
+# )
+SET(CMAKE_EXPAT_LIBRARIES expat)
SUBDIRS(Utilities/cmxmlrpc)
SET(CMAKE_XMLRPC_INCLUDES
--- Source/CPack/cmCPackTGZGenerator.cxx
+++ Source/CPack/cmCPackTGZGenerator.cxx
@@ -26,7 +26,7 @@
#include cmCPackLog.h
#include cmsys/SystemTools.hxx
-#include cmzlib/zutil.h
+#include zutil.h
#include libtar/libtar.h
#include memory // auto_ptr
#include fcntl.h
--- Source/CTest/cmCTestSubmitHandler.cxx
+++ Source/CTest/cmCTestSubmitHandler.cxx
@@ -29,7 +29,7 @@
#include xmlrpc_client.h
// For curl submission
-#include cmcurl/curl/curl.h
+#include curl/curl.h
#include sys/stat.h
--- Source/cmCTest.cxx
+++ Source/cmCTest.cxx
@@ -14,7 +14,7 @@
PURPOSE. See the above copyright notices for more information.
=*/
-#include cmcurl/curl/curl.h
+#include curl/curl.h
#include cmCTest.h
#include cmake.h
--- Source/cmGeneratedFileStream.cxx
+++ Source/cmGeneratedFileStream.cxx
@@ -27,7 +27,7 @@
#endif
#if defined(CMAKE_BUILD_WITH_CMAKE)
-# include cmzlib/zlib.h
+# include zlib.h
#endif
//
@@ -213,7 +213,7 @@
int cmGeneratedFileStreamBase::CompressFile(const char* oldname,
const char* newname)
{
- gzFile gf = cm_zlib_gzopen(newname, w);
+ gzFile gf = gzopen(newname, w);
if ( !gf )
{
return 0;
@@ -228,15 +228,15 @@
char buffer[BUFFER_SIZE];
while ( (res = fread(buffer, 1, BUFFER_SIZE, ifs)) 0 )
{
-if ( !cm_zlib_gzwrite(gf, buffer, res) )
+if ( !gzwrite(gf, buffer, res) )
{
fclose(ifs);
- cm_zlib_gzclose(gf);
+ gzclose(gf);
return 0;
}
}
fclose(ifs);
- cm_zlib_gzclose(gf);
+ gzclose(gf);
return 1;
}
#else
--- Source/cmSystemTools.cxx
+++ Source/cmSystemTools.cxx
@@ -48,7 +48,7 @@
# include libtar/libtar.h
# include memory // auto_ptr
# include fcntl.h
-# include cmzlib/zlib.h
+# include zlib.h
#endif
#if defined(__sgi) !defined(__GNUC__)
@@ -1439,7 +1439,7 @@
}
#endif
- gzf-GZFile = cm_zlib_gzdopen(fd, gzoflags);
+ gzf-GZFile = gzdopen(fd, gzoflags);
if (!gzf-GZFile)
{
errno = ENOMEM;
@@ -1452,20 +1452,20 @@
int cmSystemToolsGZStructClose(void* call_data)
{
cmSystemToolsGZStruct* gzf = static_castcmSystemToolsGZStruct*(call_data);
- return cm_zlib_gzclose(gzf-GZFile);
+ return gzclose(gzf-GZFile);
}
ssize_t cmSystemToolsGZStructRead(void* call_data, void* buf, size_t count)
{
cmSystemToolsGZStruct* gzf = static_castcmSystemToolsGZStruct*(call_data);
- return cm_zlib_gzread(gzf-GZFile, buf, count);
+ return gzread(gzf-GZFile, buf, count);
}
ssize_t cmSystemToolsGZStructWrite(void* call_data, const void* buf,
size_t count)
{
cmSystemToolsGZStruct* gzf = static_castcmSystemToolsGZStruct*(call_data);
- return cm_zlib_gzwrite(gzf-GZFile, (void*)buf, count);
+ return gzwrite(gzf-GZFile, (void*)buf, count);
}
#endif
--- Source/cmXMLParser.cxx
+++ Source/cmXMLParser.cxx
@@ -16,7 +16,7 @@
=*/
#include cmXMLParser.h
Re: Problems with uic / cmake (missing -L kde_widgetdir)
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 shortly looked into it and whoever wrote the CMakefiles has written them with no clue whatsoever. It won't work. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE/kdepim/kontact/plugins/kmail
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), just commit it and I'll notice :) ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Convenience Libraries (was RFC: KHTML modular build)
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Licensing of cmake modules?
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 exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. I'm not sure which variant is better. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Licensing of cmake modules?
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: rpaths on linux with kde3 installed
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
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: parallel make again
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 list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: parallel make again
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Problem with detection of KDE version (why is $KDEDIR/bin/kde-config used?)
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 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make install-exec
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 is not installed, it's fine for me as well. Wouldn't it be better to fix kdevelop to not be that slow instead? -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMake: please update to 2.4.0
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 weeks to get KDE trunk compiling with the coverity scanner, and I don't want to spend another 3 weeks on waiting until they could find time to update their cmake installation. -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Need help on HAVE_SMTH stuff ;)
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. Correct. Given that I introduced the --without-arts switch, I claim to know about how it was intended. (with ifdef HAVE_ARTS). However, some subdirectories in kdemultimedia afterwards changed this semantics, and I didn't have time to revert that yet. It would be nice to solve this for KDE 4.x. -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Asking for a CMake feature
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 have the same before too, by exporting INSTALL_DATA=/usr/bin/install -p In fact, we even had code to enable this by default when the install application supported it. All it needs is somebody duplicating this check in the cmake files. -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake --help case sensitivity
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 list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Difference in compilation (Re: [Kde-pim] [STATUS] Building KDEPIM with CMake)
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 mystery to me, but it boilds down to an unsermake bug. -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Difference in compilation (Re: [Kde-pim] [STATUS] Building KDEPIM with CMake)
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, non-yacc/lex, implementation. So this issue may disappear one day. Its not the first place in KDE where we use yacc/lex generated code. -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
small cmake benchmark
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 -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE/kdelibs/cmake/modules
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 fixing). Anyway, the error is: cd /suse/dmueller/src/kde/4.0/kdelibs/bgcc/dcop/dcopidl2cpp /opt/icecream/bin/c++ -pipe -Wstrict-aliasing=2 -Wall -Wextra -D_FORTIFY_SOURCE=2 -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -fno-exceptions -fno-check-new -fno-common -O2 -g -fPIC CMakeFiles/dcopidl2cpp.dir/main.o CMakeFiles/dcopidl2cpp.dir/skel.o CMakeFiles/dcopidl2cpp.dir/stub.o CMakeFiles/dcopidl2cpp.dir/stubimpl.o -o ../../bin/dcopidl2cpp -rdynamic -L/suse/dmueller/src/kde/4.0/kdelibs/bgcc/lib -L/suse/dmueller/src/kde/4.0/kdelibs/bgcc/lib/. -L/usr/local/lib -lQtCore -lpthread -lQtXml -lDCOP -lQtCore -lpthread bin/sh: line 1: 32259 Segmentation fault ../bin/dcopidl2cpp --c++-suffix cpp --no-signals --no-stub /suse/dmueller/src/kde/4.0/kdelibs/bgcc/kdecore/ksycoca.kidl make[2]: *** [kdecore/ksycoca_skel.cpp] Error 139 which is because ../bin/dcopidl2cpp links against the KDE3 libraries: $ldd bin/dcopidl2cpp | grep DCO libDCOP.so.4 = /opt/kde-35/lib/libDCOP.so.4 (0xb7d3f000) which is because bin/dcopidl2cpp doesn't have any RPATHs: $ objdump -p bin/dcopidl2cpp | grep RPATH | wc -l 0 .. as you can obviously see with the link statement above $ cmake --version cmake version 2.3-20060317 $ grep -i RPATH CMakeCache.txt CMAKE_SKIP_RPATH:BOOL=NO RPATH_STYLE:STRING=default //Advanced flag for variable: CMAKE_SKIP_RPATH CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1 I don't see how thats supposed to work, given that there is not even the slightest attempt to set a RPATH at all.. -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: nightly and continuous build setups
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 installation. -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: How to replace configure.in.bot ?
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 everything else? (the .bot in configure.in.bot means bottom of execution order). -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
