Re: cmake news: RPATH
On Thursday 23 March 2006 01:21, Brad King wrote: both - (not on OS X) I really don't like this option. Me neither. Alex, can we remove it? FYI, I anticipated this dilemma and provided a preinstall target that can be built by the user to do the relinking before changing to root: make make preinstall sudo make install Interesting workaround. Any change to the usual make [sudo] make install will remain an obscure workaround though, since nobody would even guess that there is such a solution :) As described below, relinking should only be needed for developers that want to run applications from the build tree but still install from the same tree. Right, this is why default is a rather bad default, given that most KDE applications do *not* support running from the build tree at this point. (I mean the real GUI apps). 1.) Executables that are not run during the build but are installed. 2.) Executables that are run during the build and not installed. 3.) Executables that are run during the build and are installed. Excellent analysis. Indeed we need to do things differently for those 3 kinds. - For #1 there is a choice for developers and a choice for users. Setting the target property BUILD_WITH_INSTALL_RPATH will cause the executables to get built with an RPATH meant for the install tree. No relinking is needed for installation but the executables will not run from the build tree (except on RUNPATH platforms with LD_LIBRARY_PATH set properly). This is the choice for users and should be the default. For now it would be a good default for developers too, as long as running from the builddir isn't really supported. It's good to have the option for later, of course. - For #3 there is potential trouble. When running from the build tree we need to make sure the build tree libraries are used, and when running from the install tree we need to make sure the install tree libraries are used. If BUILD_WITH_INSTALL_RPATH is set on a non-RUNPATH platform and there is an existing old install the wrong libraries will be used when running during the build. Even on a RUNPATH platform the environment must have the proper LD_LIBRARY_PATH for the build tree. Nobody sets LD_LIBRARY_PATH to point to the build tree during compilation; wrapper scripts would have to do that. If BUILD_WITH_INSTALL_RPATH is not set then relinking is required for installation even for users. Everyone would have to do make preinstall as described above. This is not an option IMHO. There are a few ways to resolve this problem: a.) Link these executables statically and build into them all the sources they need. Then no RPATH is needed at all. Since executables run during the build tend to be small generators this may not be too bad. But then we need to actually generate a static version of libkdecore Hmm. b.) Do not set BUILD_WITH_INSTALL_RPATH, document it for users, and live with the relinking. Since executables run during the build tend to be small generators relinking is not too slow. Yes, for only two binaries (see below) it would be fine. But having to teach everyone to use make preinstall, doesn't make this option worth it. c.) Enable the SKIP_BUILD_RPATH target property and set the INSTALL_RPATH property to empty. This will remove RPATHs completely from these executables. Then wrap them in a shell script or a forwarding executable like that described for option 2 in http://mail.kde.org/pipermail/kde-buildsystem/2006-January/000445.html Option (c) is a pain to setup the first time but will work very well if there are only a few such executables. Yes it sounds good to me. - The decision for #3 may depend on the number, size, and role of such executables. Can anyone respond and enumerate them please? I see the following (the sizes include debug symbols): kconfig_compiler - 637K here, creates .cpp/.h from a .kcfg (+.kcfgc) file, links to QtCore+QtXml only, so no rpath problem! makekdewidgets - 264K here, creates a .cpp (designer plugin) from a ini-style description file of widgets. Links to kdecore. meinproc - 305K here, compiles .docbook files, is run in kdelibs/doc. Links to kdecore. dcopidl2cpp - 417K here, creates a .cpp/.h from a .kidl file (DCOP interface description), links to QtCore+QtXml only. (might disappear before KDE4, too) Note: genembed - 192K here, generates code that contains pixmaps. is NOT installed. genshortcutents - 125K here, generates entities from the system-default shortcuts, for the documentation. is NOT installed. dcopidl - is perl :) Summary: only makekdewidgets and meinproc are binaries that are run during kdelibs compilation and are installed, and link to a kdelibs library.
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: qmake-qt4 vs. qmake vs. qmake-qt3
William A. Hoffman wrote: qt-copy should have a different version number. Then we can make sure we get the right version for kde. But, as it is now, you can not tell the difference from qt-copy qmake and qmake from qt 4.1.1. You can't do that because we don't know yet which version number qmake from Qt 4.2.0 will have. It might be the same as Qt 4.1.1's. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgp3WdYDmMCEh.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: kdewin32 build error
-Original Message- From: Christian Ehrlicher [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 22 de Março de 2006 21:15 To: kde-buildsystem@kde.org Subject: Re: kdewin32 build error Is it possible to build and install qt-copy on Windows? It has the patches applied or it has to be done manually? Thanks for the info. Ralf already answered this. Apply all patches from qt-copy/patches and recompile qt/win. But my question makes sense, as qt-copy is not prepared to build on windows and some patches are already applied (including the mentioned one) :) Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: kdewin32 build error
-Original Message- From: Paulo Jorge Guedes [mailto:[EMAIL PROTECTED] Sent: quinta-feira, 23 de Março de 2006 11:38 To: kde-buildsystem@kde.org Subject: RE: kdewin32 build error -Original Message- From: Christian Ehrlicher [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 22 de Março de 2006 21:15 To: kde-buildsystem@kde.org Subject: Re: kdewin32 build error Is it possible to build and install qt-copy on Windows? It has the patches applied or it has to be done manually? Thanks for the info. Ralf already answered this. Apply all patches from qt-copy/patches and recompile qt/win. But my question makes sense, as qt-copy is not prepared to build on windows and some patches are already applied (including the mentioned one) :) Nevermind: requires currently that you take the latest qt sources from trolltech This mornings are not easy :/ Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake: make Qt4 qmake available via PATH
On Thu, Mar 23, 2006 at 10:33:06AM +0100, Thiago Macieira wrote: Michael Olbrich wrote: $ ls `qmake -query QT_INSTALL_BINS`/uic /home/tjmaciei/troll/qt-4.1-build/bin/uic* $ ls `pkg-config --variable prefix QtCore`/bin/uic /home/tjmaciei/troll/qt-4.1-build/bin/uic* That is not necessarily the same uic qmake would use. Is that intentional? It is, unless you change it intentionally. $ head mkspecs/features/uic.prf [...] What I mean is, it _can_ be changed. Debian has modified mkspecs/linux-g++/qmake.conf: QMAKE_MOC = $$[QT_INSTALL_BINS]/moc-qt4 QMAKE_UIC = $$[QT_INSTALL_BINS]/uic-qt4 The question is, how can a buildsystem like cmake figure out which moc/uic qmake would use. That way we can be sure that header/libs/tools are all from the same qt version. michael ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake: make Qt4 qmake available via PATH
Michael Olbrich wrote: What I mean is, it _can_ be changed. Debian has modified mkspecs/linux-g++/qmake.conf: QMAKE_MOC = $$[QT_INSTALL_BINS]/moc-qt4 QMAKE_UIC = $$[QT_INSTALL_BINS]/uic-qt4 The question is, how can a buildsystem like cmake figure out which moc/uic qmake would use. That way we can be sure that header/libs/tools are all from the same qt version. This is Debian's problem. Qt installs a meta object compiler called moc. If you rename it to moc-qt4 or yet-another-precompilation-compiler, it's your problem. I'm sorry, we cannot support every small change out there. It was bad enough trying to detect automake/autoconf friends when distributions started installing 2, 3 or even 4 different versions of those tools! Besides, this is only happening because Qt 4 changed all the library names. Since we don't have libqt.so or libqt-mt.so, distributions started thinking that they can install the development files for *both* libraries in the same prefix. And while the libraries don't clash, there are header files to take into account, and other tools. So, in my vision, installing them into the same prefix is asking for trouble. Renaming the executables is even worse! Put them into /opt or /usr/lib. This is how some distributions solved the problem in Qt 2 vs Qt 3 times. Why not do it again? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgpage4IUSVeo.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: nightly and continuous build setups
At 10:19 AM 3/23/2006, you wrote: just linux. i don't have a seperate windows machine here to test on. Hey cool, it worked, I can see your continuous build. What type of machine is that? It built in 45 minutes? -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: nightly and continuous build setups
On Thu, Mar 23, 2006 at 11:51:26AM -0500, William A. Hoffman wrote: At 10:19 AM 3/23/2006, you wrote: just linux. i don't have a seperate windows machine here to test on. Hey cool, it worked, I can see your continuous build. What type of machine is that? It built in 45 minutes? It's an AMD64 3000. It's running archlinux 0.7.1 in 32-bit mode. and yes, it built in 45 minutes. -- Matt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changing the CMAKE_VERBOSE_MAKEFILES in ccmake has no effect.
Matt Rogers wrote: If i use ccmake to configure the build and change CMAKE_VERBOSE_MAKEFILE to OFF, the setting has no effect and I have to manually edit the CMakeLists.txt file in order to turn off verbosity. Is this the intended effect? This is because the top level CMakeLists.txt file in KDE hard-codes the setting to ON and ignores the cache value. Now that things are up-and-running the setting should probably be removed. CMake's default is OFF, but it provides the advanced cache option to allow users to turn it ON. Also, even if it is off one can do make VERBOSE=1 or VERBOSE=1 make to turn it on for just one build. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: nightly and continuous build setups
At 01:30 PM 3/23/2006, Matt Rogers wrote: On Thu, Mar 23, 2006 at 11:51:26AM -0500, William A. Hoffman wrote: At 10:19 AM 3/23/2006, you wrote: just linux. i don't have a seperate windows machine here to test on. Hey cool, it worked, I can see your continuous build. What type of machine is that? It built in 45 minutes? It's an AMD64 3000. It's running archlinux 0.7.1 in 32-bit mode. and yes, it built in 45 minutes. Cool! BTW, you can still run a nightly at any point. Also, be sure to use separate svn checkouts for the nightly and the continuous. The nightly is checked out with a date stamp so that all machines doing nightly builds are using the same code base. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Native support for CMake in KDevelop 4
On Thursday 23 March 2006 02:03, Matt Rogers wrote: Hi, I'd like to start working on native CMake support for KDevelop 4. What I mean by this is that when you open a project that is set up to use CMake, the CMakeLists.txt files plus any additional cmake macros are automatically loaded in and can be edited natively? Does CMake have a library that can be linked to by a KDevelop plugin in order to reuse CMake's parsing code to produce something like an abstract syntax tree that can be used by this plugin? If not, how feasible would it be to provide this? Posted here instead of cmake@cmake.org since i'm not subscribing to that list for just one post. When compiling cmake there is a static lib generated. I don't have time right now but I wrote some small test app which used this lib. It doesn't get installed, but maybe you could reuse the sources. Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changing the CMAKE_VERBOSE_MAKEFILES in ccmake has no effect.
On Thursday 23 March 2006 19:36, David Faure wrote: On Thursday 23 March 2006 19:33, Matt Rogers wrote: Hi! If i use ccmake to configure the build and change CMAKE_VERBOSE_MAKEFILE to OFF, the setting has no effect and I have to manually edit the CMakeLists.txt file in order to turn off verbosity. Is this the intended effect? I think the hardcoded ON from CMakeLists.txt should be removed. Ok, can you pelase remove it ? I don't have time to do it today. Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Native support for CMake in KDevelop 4
Alexander Neundorf wrote: On Thursday 23 March 2006 02:03, Matt Rogers wrote: Hi, I'd like to start working on native CMake support for KDevelop 4. What I mean by this is that when you open a project that is set up to use CMake, the CMakeLists.txt files plus any additional cmake macros are automatically loaded in and can be edited natively? Does CMake have a library that can be linked to by a KDevelop plugin in order to reuse CMake's parsing code to produce something like an abstract syntax tree that can be used by this plugin? If not, how feasible would it be to provide this? Posted here instead of cmake@cmake.org since i'm not subscribing to that list for just one post. When compiling cmake there is a static lib generated. I don't have time right now but I wrote some small test app which used this lib. It doesn't get installed, but maybe you could reuse the sources. We (CMake devs) are talking about ways to share the parser implementation with KDevelop or other projects. We'll get back to you when we've reached a decision. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: nightly and continuous build setups
One more thing, I just added this: KDE4_BUILD_TESTS:BOOL=ON To both my nightly and continuous builds so that the tests will be run as well. -Bill ___ 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: changing the CMAKE_VERBOSE_MAKEFILES in ccmake has no effect.
On Thu, Mar 23, 2006 at 07:55:35PM +0100, David Faure wrote: On Thursday 23 March 2006 19:34, William A. Hoffman wrote: At 01:33 PM 3/23/2006, Matt Rogers wrote: Hi! If i use ccmake to configure the build and change CMAKE_VERBOSE_MAKEFILE to OFF, the setting has no effect and I have to manually edit the CMakeLists.txt file in order to turn off verbosity. Is this the intended effect? The forced value in the CMakeLists.txt file should be removed. I think Alex said he was going to remove it, but has not yet gotten around to doing it. I'll do it in kdelibs and kdebase since I'm doing large CMakeLists.txt changes there at the moment. Thanks! -- Matt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: nightly and continuous build setups
At 02:36 PM 3/23/2006, Dirk Mueller wrote: 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. OK, maybe I should remove that. Although there should be a way to run the tests from the dashboard. It is sort of the point of having a dashboard (to run tests) Can anything be done about this, or do you have to install to run the tests? -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: nightly and continuous build setups
At 02:39 PM 3/23/2006, William A. Hoffman wrote: At 02:36 PM 3/23/2006, Dirk Mueller wrote: 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. OK, maybe I should remove that. Although there should be a way to run the tests from the dashboard. It is sort of the point of having a dashboard (to run tests) Can anything be done about this, or do you have to install to run the tests? Well, looks like the test do not even build right now. :( http://public.kitware.com/KDE/Testing/Sites/matt.rogers.name/Linux-Archlinux-gcc4.0.3/20060323-1939-Continuous/BuildError.html -Bill ___ 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 21:07, William A. Hoffman wrote: At 02:39 PM 3/23/2006, William A. Hoffman wrote: At 02:36 PM 3/23/2006, Dirk Mueller wrote: 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. OK, maybe I should remove that. Although there should be a way to run the tests from the dashboard. It is sort of the point of having a dashboard (to run tests) Can anything be done about this, or do you have to install to run the tests? I fixed the katepart regression test to not run it when kdelibs isn't installed yet, let's see if that was enough. http://public.kitware.com/KDE/Testing/Sites/matt.rogers.name/Linux-Archlinux-gcc4.0.3/20060323-1939-Continuous/BuildError.html khtml's testregression is a rather special build, a developer tool in a way. It shouldn't be built by default, but rather by a special target. In the old buildsystem this would mean make check wouldn't build it, but make testregression would. Can we do something similar with cmake? -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: nightly and continuous build setups
At 06:43 PM 3/23/2006, David Faure wrote: I fixed the katepart regression test to not run it when kdelibs isn't installed yet, let's see if that was enough. http://public.kitware.com/KDE/Testing/Sites/matt.rogers.name/Linux-Archlinux-gcc4.0.3/20060323-1939-Continuous/BuildError.html khtml's testregression is a rather special build, a developer tool in a way. It shouldn't be built by default, but rather by a special target. In the old buildsystem this would mean make check wouldn't build it, but make testregression would. Can we do something similar with cmake? In cmake, it would be better to just make it a cmake option that you specify in at compile time. Is there a reason you do not want to do that? -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
kdelibs4_snapshot uninstallable (kde3init_dummy.cpp.in) with cmake
cmake/modules/CMakeLists.txt in kdelibs4_snapshot still references kde3init_dummy.cpp.in which makes make install fail. It would be a good idea imo to merge back the changes from trunk where this seems to be fixed already. Michael ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
