A Better Error Message?
Howdy CMakers, I completely removed my KDE4 install dir, and then mistakenly tried to build kdepim before kdelibs4_snapshot. So, I got the following from CMake: Re-run cmake no build system arguments -- Check for working C compiler: gcc -- Check for working C compiler: gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: c++ -- Check for working CXX compiler: c++ -- works ERROR: cmake/modules/FindKDE4Internal.cmake not found in /misc/home/winterz/.kde4/share/apps/;/usr/share/apps/ -- Configuring done I was wondering if we could do better than the error message above. Perhaps something like: "ERROR: cmake/modules/FindKDE4Internal.cmake not found in /misc/home/winterz/.kde4/share/apps/;/usr/share/apps/ Did you forget to install kdelibs first?" Is this possible? -Allen -- Let's Keep the Political Talk Out of KDE PLEASE ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [REQUEST] CMake Snapshot Update
On 4/17/06, William A. Hoffman <[EMAIL PROTECTED]> wrote: > How about I make the cmake release without the FindQt. > Then you can put your changes into kde. There are some other > changes I want in FindQt4 as well, and they are best tested > in kde. Once we are sure they are working with 2.4 then we > can put them in 2.4.1. That sounds like a good idea. Cheers, Tanner Lovelace -- Tanner Lovelace clubjuggler at gmail dot com http://wtl.wayfarer.org/ (fieldless) In fess two roundels in pale, a billet fesswise and an increscent, all sable. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [REQUEST] CMake Snapshot Update
At 04:50 PM 4/17/2006, Tanner Lovelace wrote: >On 4/17/06, William A. Hoffman <[EMAIL PROTECTED]> wrote: >> I am going to branch CMake 2.4 today, and was thinking of using that for >> the next kde release. I should have it ready by tomorrow. > >Will you be grabbing the FindQt4.cmake from KDE for the new cmake >release? I've got a patch for it but have been waiting on a new >KDE cmake release before applying it since it relys on the >fix for OS X frameworks I submitted a couple of weeks ago. > >If so, could you also please apply the attached patch. >All it does is remove the special framework handling >under OS X. The reworked framework library handling >in the current CMake CVS makes the special case unnecessary. How about I make the cmake release without the FindQt. Then you can put your changes into kde. There are some other changes I want in FindQt4 as well, and they are best tested in kde. Once we are sure they are working with 2.4 then we can put them in 2.4.1. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [REQUEST] CMake Snapshot Update
On 4/17/06, William A. Hoffman <[EMAIL PROTECTED]> wrote: > I am going to branch CMake 2.4 today, and was thinking of using that for > the next kde release. I should have it ready by tomorrow. Will you be grabbing the FindQt4.cmake from KDE for the new cmake release? I've got a patch for it but have been waiting on a new KDE cmake release before applying it since it relys on the fix for OS X frameworks I submitted a couple of weeks ago. If so, could you also please apply the attached patch. All it does is remove the special framework handling under OS X. The reworked framework library handling in the current CMake CVS makes the special case unnecessary. Thanks, Tanner Lovelace -- Tanner Lovelace clubjuggler at gmail dot com http://wtl.wayfarer.org/ (fieldless) In fess two roundels in pale, a billet fesswise and an increscent, all sable. findqt4-framework-simplify.patch Description: Binary data ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: MAKE_KDEFX_LIB
> -Original Message-
> From: Paulo Jorge Guedes [mailto:[EMAIL PROTECTED]
> Sent: segunda-feira, 17 de Abril de 2006 19:35
> To: kde-buildsystem@kde.org
> Subject: MAKE_KDEFX_LIB
>
> Hi,
>
> Currently MAKE_KDEFX_LIB is not being defined, which causes linkage
> errors in kstyles:
>
> #ifndef KDEFX_EXPORT
> # ifdef MAKE_KDEFX_LIB
> # define KDEFX_EXPORT KDE_EXPORT
> # else
> # define KDEFX_EXPORT KDE_IMPORT
> # endif
> #endif
>
> Would this be a correct fix into kdelibs/CMakeLists.txt?
>
> -add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS}
> -DHAVE_CONFIG_H=1)
> +add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS}
-DHAVE_CONFIG_H=1
> -DMAKE_KDEFX_LIB)
Obviously not :)
This defines are generated into flags.make and the one in question is
indeed in the kdefx.dir.
Don't know why it doesn't work... the above fixes it (although the wrong
fix).
Paulo
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [REQUEST] CMake Snapshot Update
At 01:11 PM 4/17/2006, Allen Winter wrote: >On Monday 17 April 2006 13:09, William A. Hoffman wrote: >> At 12:33 PM 4/17/2006, Allen Winter wrote: >> >Hi CMake Developers, >> > >> >I'd like to suggest that it is time for a new snapshot. There are some >> >buglets in the >> >http://www.cmake.org/files/v2.3/cmake-2.3.4-20060317.tar.gz that are >> >causing some >> >unneeded pain (like the -L out-of-order problem). >> > >> >So, if you have the chance, could you please tear us off a new snapshot and >> >put it >> >in http://www.cmake.org/files/v2.3 ? >> > >> >Once done, I'll update http://wiki.kde.org/tiki-index.php?page=KDECMakeIntro >> >> I am going to branch CMake 2.4 today, and was thinking of using that for >> the next kde release. I should have it ready by tomorrow. >> >Thanks Bill. >This is even more than I asked for... once more the CMake Devs are "exceeding >expectations" ;> No problem. There is one issue. That is the visual studio IDE problem. No one has really answered me on that one. If it is going to be a cmake solution, where we have to add something to cmake, I would like to do it before 2.4. However, I think it can be done without any changes to cmake. Any comments? -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [REQUEST] CMake Snapshot Update
At 02:34 PM 4/17/2006, Craig Bradney wrote: >> I am going to branch CMake 2.4 today, and was thinking of using that for >> the next kde release. I should have it ready by tomorrow. > >Great! Release as well? I was planning on doing a 2.4.0 beta with a windows binary, and source code tar file for unix/mac. It will be an official cmake release. For 2.4.1, I will create the usual binaries for cmake. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
KDE/kdelibs/libltdl
SVN commit 530825 by mojo:
Export this methods; needed for Windows.
CCMAIL: kde-buildsystem@kde.org
M +6 -4 ltdl.c
--- trunk/KDE/kdelibs/libltdl/ltdl.c #530824:530825
@@ -25,6 +25,8 @@
*/
+#include
+
#if HAVE_CONFIG_H
# include
#endif
@@ -1300,7 +1302,7 @@
static int initialized = 0;
/* Initialize libltdl. */
-int
+KDECORE_EXPORT int
lt_dlinit ()
{
interrors = 0;
@@ -2033,7 +2035,7 @@
return 0;
}
-lt_dlhandle
+KDECORE_EXPORT lt_dlhandle
lt_dlopen (filename)
const char *filename;
{
@@ -2586,7 +2588,7 @@
return errors;
}
-lt_ptr
+KDECORE_EXPORT lt_ptr
lt_dlsym (handle, symbol)
lt_dlhandle handle;
const char *symbol;
@@ -2689,7 +2691,7 @@
return address;
}
-const char *
+KDECORE_EXPORT const char *
lt_dlerror ()
{
const char *error;
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
MAKE_KDEFX_LIB
Hi,
Currently MAKE_KDEFX_LIB is not being defined, which causes linkage
errors in kstyles:
#ifndef KDEFX_EXPORT
# ifdef MAKE_KDEFX_LIB
# define KDEFX_EXPORT KDE_EXPORT
# else
# define KDEFX_EXPORT KDE_IMPORT
# endif
#endif
Would this be a correct fix into kdelibs/CMakeLists.txt?
-add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS}
-DHAVE_CONFIG_H=1)
+add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS} -DHAVE_CONFIG_H=1
-DMAKE_KDEFX_LIB)
Paulo
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [REQUEST] CMake Snapshot Update
On Monday 17 April 2006 19:09, William A. Hoffman wrote: > At 12:33 PM 4/17/2006, Allen Winter wrote: > >Hi CMake Developers, > > > >I'd like to suggest that it is time for a new snapshot. There are some > > buglets in the > > http://www.cmake.org/files/v2.3/cmake-2.3.4-20060317.tar.gz that are > > causing some unneeded pain (like the -L out-of-order problem). > > > >So, if you have the chance, could you please tear us off a new snapshot > > and put it in http://www.cmake.org/files/v2.3 ? > > > >Once done, I'll update > > http://wiki.kde.org/tiki-index.php?page=KDECMakeIntro > > I am going to branch CMake 2.4 today, and was thinking of using that for > the next kde release. I should have it ready by tomorrow. Great! Release as well? Craig ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: ltdl.c in kinit
On Mon, Apr 17, 2006 at 06:53:10PM +0100, Paulo Jorge Guedes wrote: > > -Original Message- > > From: Paulo Jorge Guedes [mailto:[EMAIL PROTECTED] > > Sent: segunda-feira, 17 de Abril de 2006 18:36 > > To: David Faure; kde-buildsystem@kde.org > > Subject: RE: ltdl.c in kinit > > > > > I guess those methods need to be declared with KDECORE_EXPORT then; > > can > > > you try that? > > > > It works :) > > KDECORE_EXPORT doesn't work (yes, I included kdemacros.h), I had to > use > > __declspec(dllexport) directly. > > Ups, the include for KDECORE_EXPORT is in kdelibs_export_win.h :) > But, as ltdl.c doesn't belong to kdecore, doesn't KDE_EXPORT should be > used instead? ltdl.c is compiled into libkdecore. David. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: ltdl.c in kinit
> -Original Message- > From: Paulo Jorge Guedes [mailto:[EMAIL PROTECTED] > Sent: segunda-feira, 17 de Abril de 2006 18:36 > To: David Faure; kde-buildsystem@kde.org > Subject: RE: ltdl.c in kinit > > > I guess those methods need to be declared with KDECORE_EXPORT then; > can > > you try that? > > It works :) > KDECORE_EXPORT doesn't work (yes, I included kdemacros.h), I had to use > __declspec(dllexport) directly. Ups, the include for KDECORE_EXPORT is in kdelibs_export_win.h :) But, as ltdl.c doesn't belong to kdecore, doesn't KDE_EXPORT should be used instead? Paulo > BTW, is this obsolete? > > #ifdef DLL_EXPORT > # define LT_GLOBAL_DATA __declspec(dllexport) > #else > # define LT_GLOBAL_DATA > #endif ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: ltdl.c in kinit
> -Original Message-
> From: David Faure [mailto:[EMAIL PROTECTED]
> Sent: segunda-feira, 17 de Abril de 2006 17:55
> To: Paulo Jorge Guedes
> Subject: Re: ltdl.c in kinit
>
> On Mon, Apr 17, 2006 at 05:22:06PM +0100, Paulo Jorge Guedes wrote:
> > Hi,
> >
> > This commit:
> >
> > --- CMakeLists.txt (revision 530673)
> > +++ CMakeLists.txt (working copy)
> > @@ -84,7 +84,7 @@
> > ### next target ###
> > -set(kioslave_SRCS kioslave.cpp)
> > +set(kioslave_SRCS kioslave.cpp ${CMAKE_SOURCE_DIR}/libltdl/ltdl.c)
> > kde4_automoc(${kioslave_SRCS})
> >
> > The code from ltdl.c is already in libkdecore, which kioslave links
to,
> > so no need to add it again.
> >
> >
> > breaks linkage on Windows (both mingw and msvc). It makes sense
though
> > :)
> > There is a similar case with kstyles/keramic.
> >
> > CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
> > d:/kde/kdelibs/kinit/kioslave.cpp:66: undefined reference to
`lt_dlinit'
> > CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
> >
D:/downloads/qt-win-opensource-src-4.1.1/include/QtCore/qbytearray.h:329
> > : undefined reference to `lt_dlopen'
> > CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
> > d:/kde/kdelibs/kinit/kioslave.cpp:76: undefined reference to
`lt_dlsym'
> > d:/kde/kdelibs/kinit/kioslave.cpp:71: undefined reference to
> > `lt_dlerror'
> > d:/kde/kdelibs/kinit/kioslave.cpp:79: undefined reference to
`lt_dlsym'
> > d:/kde/kdelibs/kinit/kioslave.cpp:82: undefined reference to
> > `lt_dlerror'
> > collect2: ld returned 1 exit status
>
> I guess those methods need to be declared with KDECORE_EXPORT then;
can
> you try that?
It works :)
KDECORE_EXPORT doesn't work (yes, I included kdemacros.h), I had to use
__declspec(dllexport) directly.
BTW, is this obsolete?
#ifdef DLL_EXPORT
# define LT_GLOBAL_DATA__declspec(dllexport)
#else
# define LT_GLOBAL_DATA
#endif
Paulo
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [REQUEST] CMake Snapshot Update
On Monday 17 April 2006 13:09, William A. Hoffman wrote: > At 12:33 PM 4/17/2006, Allen Winter wrote: > >Hi CMake Developers, > > > >I'd like to suggest that it is time for a new snapshot. There are some > >buglets in the > >http://www.cmake.org/files/v2.3/cmake-2.3.4-20060317.tar.gz that are > >causing some > >unneeded pain (like the -L out-of-order problem). > > > >So, if you have the chance, could you please tear us off a new snapshot and > >put it > >in http://www.cmake.org/files/v2.3 ? > > > >Once done, I'll update http://wiki.kde.org/tiki-index.php?page=KDECMakeIntro > > I am going to branch CMake 2.4 today, and was thinking of using that for > the next kde release. I should have it ready by tomorrow. > Thanks Bill. This is even more than I asked for... once more the CMake Devs are "exceeding expectations" ;> -Allen -- Let's Keep the Political Talk Out of KDE PLEASE ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [REQUEST] CMake Snapshot Update
At 12:33 PM 4/17/2006, Allen Winter wrote: >Hi CMake Developers, > >I'd like to suggest that it is time for a new snapshot. There are some >buglets in the >http://www.cmake.org/files/v2.3/cmake-2.3.4-20060317.tar.gz that are causing >some >unneeded pain (like the -L out-of-order problem). > >So, if you have the chance, could you please tear us off a new snapshot and >put it >in http://www.cmake.org/files/v2.3 ? > >Once done, I'll update http://wiki.kde.org/tiki-index.php?page=KDECMakeIntro I am going to branch CMake 2.4 today, and was thinking of using that for the next kde release. I should have it ready by tomorrow. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: ltdl.c in kinit
Sorry, wrong diff:
--- CMakeLists.txt (revision 527865)
+++ CMakeLists.txt (revision 529848)
@@ -84,13 +84,7 @@
### next target ###
-if(WIN32)
- set(kioslave_SRCS kioslave.cpp
- ${CMAKE_SOURCE_DIR}/libltdl/ltdl.c
- ${CMAKE_SOURCE_DIR}/libltdl/ltdl_win.c)
-else(WIN32)
- set(kioslave_SRCS kioslave.cpp ${CMAKE_SOURCE_DIR}/libltdl/ltdl.c)
-endif(WIN32)
+set(kioslave_SRCS kioslave.cpp)
> -Original Message-
> From: Paulo Jorge Guedes [mailto:[EMAIL PROTECTED]
> Sent: segunda-feira, 17 de Abril de 2006 17:22
> To: kde-buildsystem@kde.org; David Faure
> Subject: ltdl.c in kinit
>
> Hi,
>
> This commit:
>
> --- CMakeLists.txt (revision 530673)
> +++ CMakeLists.txt (working copy)
> @@ -84,7 +84,7 @@
> ### next target ###
> -set(kioslave_SRCS kioslave.cpp)
> +set(kioslave_SRCS kioslave.cpp ${CMAKE_SOURCE_DIR}/libltdl/ltdl.c)
> kde4_automoc(${kioslave_SRCS})
>
> The code from ltdl.c is already in libkdecore, which kioslave links
to,
> so no need to add it again.
>
>
> breaks linkage on Windows (both mingw and msvc). It makes sense though
> :)
> There is a similar case with kstyles/keramic.
>
> CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
> d:/kde/kdelibs/kinit/kioslave.cpp:66: undefined reference to
`lt_dlinit'
> CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
>
D:/downloads/qt-win-opensource-src-4.1.1/include/QtCore/qbytearray.h:329
> : undefined reference to `lt_dlopen'
> CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
> d:/kde/kdelibs/kinit/kioslave.cpp:76: undefined reference to
`lt_dlsym'
> d:/kde/kdelibs/kinit/kioslave.cpp:71: undefined reference to
> `lt_dlerror'
> d:/kde/kdelibs/kinit/kioslave.cpp:79: undefined reference to
`lt_dlsym'
> d:/kde/kdelibs/kinit/kioslave.cpp:82: undefined reference to
> `lt_dlerror'
> collect2: ld returned 1 exit status
>
> Paulo
> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
[REQUEST] CMake Snapshot Update
Hi CMake Developers, I'd like to suggest that it is time for a new snapshot. There are some buglets in the http://www.cmake.org/files/v2.3/cmake-2.3.4-20060317.tar.gz that are causing some unneeded pain (like the -L out-of-order problem). So, if you have the chance, could you please tear us off a new snapshot and put it in http://www.cmake.org/files/v2.3 ? Once done, I'll update http://wiki.kde.org/tiki-index.php?page=KDECMakeIntro Regards, Allen -- Let's Keep the Political Talk Out of KDE PLEASE ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
ltdl.c in kinit
Hi,
This commit:
--- CMakeLists.txt (revision 530673)
+++ CMakeLists.txt (working copy)
@@ -84,7 +84,7 @@
### next target ###
-set(kioslave_SRCS kioslave.cpp)
+set(kioslave_SRCS kioslave.cpp ${CMAKE_SOURCE_DIR}/libltdl/ltdl.c)
kde4_automoc(${kioslave_SRCS})
The code from ltdl.c is already in libkdecore, which kioslave links to,
so no need to add it again.
breaks linkage on Windows (both mingw and msvc). It makes sense though
:)
There is a similar case with kstyles/keramic.
CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
d:/kde/kdelibs/kinit/kioslave.cpp:66: undefined reference to `lt_dlinit'
CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
D:/downloads/qt-win-opensource-src-4.1.1/include/QtCore/qbytearray.h:329
: undefined reference to `lt_dlopen'
CMakeFiles/kioslave.dir/kioslave.obj: In function `main':
d:/kde/kdelibs/kinit/kioslave.cpp:76: undefined reference to `lt_dlsym'
d:/kde/kdelibs/kinit/kioslave.cpp:71: undefined reference to
`lt_dlerror'
d:/kde/kdelibs/kinit/kioslave.cpp:79: undefined reference to `lt_dlsym'
d:/kde/kdelibs/kinit/kioslave.cpp:82: undefined reference to
`lt_dlerror'
collect2: ld returned 1 exit status
Paulo
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Breaking a foreach loop
Hello,
imagine I'm iterating using a foreach() like this:
set(MY_OPTS "foo bar etc")
foreach(OPT ${MY_OPTS})
# do something ...
endforeach(OPT ${MY_OPTS})
is there a way to break the iteration, just like a break in C?
Whether it exist, does it break even nested foreach()?
Regards,
--
Pino Toscano
pgp5RZCytT6nT.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE/kdegraphics/kfile-plugins
On Mon, Apr 17, 2006 at 02:39:02PM +0200, Laurent Montel wrote:
> On Monday 17 April 2006 14:35, David Faure wrote:
> > On Fri, Apr 14, 2006 at 12:14:16PM +, Laurent Montel wrote:
> > > SVN commit 529768 by mlaurent:
> > >
> > > Fix cmake variable
> > >
> > >
> > > M +1 -1 exr/CMakeLists.txt
> > > M +1 -1 jpeg/CMakeLists.txt
> > > M +1 -1 png/CMakeLists.txt
> > > M +1 -1 ps/CMakeLists.txt
> > > M +1 -1 raw/CMakeLists.txt
> > > M +1 -1 tiff/CMakeLists.txt
> > > M +1 -1 xpm/CMakeLists.txt
> > >
> > >
> > > --- trunk/KDE/kdegraphics/kfile-plugins/exr/CMakeLists.txt #529767:529768
> > > @@ -14,7 +14,7 @@
> > >
> > > kde4_install_libtool_file( ${PLUGIN_INSTALL_DIR} kfile_exr )
> > >
> > > -target_link_libraries(kfile_exr ${KDE4_KIO_LIBRARIES}
> > > ${OPENEXR_LIBRARIES} ) +target_link_libraries(kfile_exr ${KDE4_KIO_LIBS}
> > > ${OPENEXR_LIBRARIES} )
> >
> > Hmm, really? I thought it was KDE4_KIO_LIBRARIES ?
>
> No KDE4_KIO_LIBRARIES is just -lkio
> but # KDE4_KIO_LIBS - the kio library and all depending libraries
>
> So for building it we must add all dependancy
This is very surprising. I thought the usual way in cmake was like
KDE4_KIO_LIBRARY (just kio)
KDE4_KIO_LIBRARIES (kio and dependent libs)
This is what was done for X11, Qt, pcre, openssl, agg, akode ... i.e.
everything else in kdelibs/cmake/modules.
But indeed not for the kde libs.
Hmm - what does kde-buildsystem think?
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [MSVC8] libxml2 and libiconv
On 4/17/06, Thiago Macieira <[EMAIL PROTECTED]> wrote: > On MacOS X, from what I hear, the frameworks have both libraries -- i.e., > nothing + "_debug". So it looks like we should support the same. Yes, but I believe when linking you only specify the main name of the framework. To have it use the debug version you set the DYLD_IMAGE_SUFFIX environment variable to _debug like this: DYLD_IMAGE_SUFFIX=_debug and that causes it to load the debug framework at runtime. It can also be enabled from within XCode. Ref: http://developer.apple.com/technotes/tn2004/tn2124.html#SECDEBUGLIB Cheers, Tanner -- Tanner Lovelace clubjuggler at gmail dot com http://wtl.wayfarer.org/ (fieldless) In fess two roundels in pale, a billet fesswise and an increscent, all sable. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: visual studio ide problems
At 04:58 PM 4/14/2006, William A. Hoffman wrote:
>There are some PATH issues with visual studio and kdelibs.
>
>To successfully build kdelibs with the ide, you have to have perl
>and the qt dll's in your PATH during the build. The visual studio
>IDE has its own environment. It can be set, but it is not a common
>thing to do. (In fact, I am not even sure where the menu is to
>set the PATH, but I am sure I could find it.) So, most developers
>will run cmake, then load the solution and try to build. They will
>get errors, and give up. Even if you run the IDE from a shell, it does not get
>that environment. I have some ideas for fixes:
>
>1. For windows, every tool that is run during the build, gets run
>from a driver .bat file. The driver bat file is a configured
>file that has the correct paths built into it.
>
>kdewindriver.bat ${KDE4_DCOPIDL2CPP_EXECUTABLE}
>
>kdewindriver.bat ${KDE4_DCOPIDL_EXECUTABLE}
>
>It would work with the nmake and ide builds reducing the environment
>setup needed to run the build.
>
>2. I add some sort of global variable that allows you to set PATH
>in ALL custom commands in CMake. It is possible in a custom command
>to do set PATH=c:/perl/bin;%PATH% as part of the command.
>
>SET(CMAKE_CUSTOM_COMMAND_WINDOWS_PATH /path/to/qt/bin;/path/to/perl)
>
>This would work only with VS IDE.
>
>pros: It is a small fix to cmake.
>cons: It is specific to only one generator.
>
>This is much like the rpath problem on unix.
>I am thinking that 1 maybe a better way to go.
>Any other ideas?
I have another idea. Perhaps this is similar to the RPATH problem.
Maybe a cmake script should be used to launch kde programs during
the build process. So, kde4_exec_via_sh should not be a shell
script, but rather a .cmake script run with cmake -P.
For windows this script would set PATH, and for unix it would set
_library_path_variable.
-Bill
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: KDE/kdelibs/kdeui
On 4/17/06, Paulo Moura Guedes <[EMAIL PROTECTED]> wrote: > SVN commit 530679 by mojo: > > Don't use X11 includes on Windows. > > CCMAIL: kde-buildsystem@kde.org > > M +1 -1 kkeyserver.h > > > --- trunk/KDE/kdelibs/kdeui/kkeyserver.h #530678:530679 > @@ -23,7 +23,7 @@ > #ifndef _KKEYSERVER_H > #define _KKEYSERVER_H > > -#if defined Q_WS_X11 or defined Q_WS_WIN > +#if defined Q_WS_X11 /*or defined Q_WS_WIN*/ > #include "kkeyserver_x11.h" > #elif defined Q_WS_MACX > #include "kkeyserver_mac.h" Is there any reason to prefer Q_WS_MACX over Q_WS_MAC? Since Qt doesn't work on pre OS X and pre OS X macs are pretty much dead (especially with the switch to Intel) that Q_WS_MAC be used instead. That's what I had setup in FindQt4.cmake. Cheers, Tanner Lovelace -- Tanner Lovelace clubjuggler at gmail dot com http://wtl.wayfarer.org/ (fieldless) In fess two roundels in pale, a billet fesswise and an increscent, all sable. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Wrong order of -L?
Alexander Dymo wrote:
> I've noticed this when compiling kdevelop today.
> We have -L listed first in the compiler command
> line. This leads to link errors because wrong libraries are picked up.
> It links old installed libraries and not newer ones from the source tree.
>
> In kdevelop/src/CMakeLists.txt we have
> ...
> target_link_libraries(kdevshell ${KDE4_KDECORE_LIBS} kdeui profileengine
> kdevinterfaces kdevutil kdevwidgets newui khtml ktexteditor)
> ..
>
> And when libkdevwidgets.so from build dir contains new symbols, the link
> ends with an error:
>
> /usr/bin/c++ ... -L/home/gremlin/bin/kde4/lib
> -L/home/gremlin/projects/oss/kde_svn/trunk/kdevelop_build/lib ... -lkdecore
> -lkdeui -lprofileengine -lkdevinterfaces -lkdevutil -lkdevwidgets -lnewui
> -lkhtml -lktexteditor -lkdevinterfaces ...
> ...
> undefined reference to ...
>
> The error is because of the wrong order of -L parameters.
> -L/home/gremlin/bin/kde4/lib should go after -L pathes to the build dir.
>
> Can the order be changed somehow?
This has been fixed in CVS CMake since the last KDE release.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [MSVC8] libxml2 and libiconv
Christian Ehrlicher wrote:
>Because MSVC is using two different msvcrt - libraries (one release and
>one debug version) you can't mix debug and release libs without a crash
>sooner or later. Qt introduced the debug-prefix ('d' or '_debug') to
>work around this problem and we need this for kde too. I don't know any
>other way to be sure to not mix the libs... :-(
Ok, so we need to support that on Windows. I.e., if we're linking against
the debug Qt build, we generate debugging ('d') libraries.
On MacOS X, from what I hear, the frameworks have both libraries -- i.e.,
nothing + "_debug". So it looks like we should support the same.
On all the other Unix, I'd rather we didn't introduce anything right now.
Switching libraries is very useful and I'd rather not have to rebuild my
whole KDE just because I want to debug something in kdecore or Qt.
--
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
pgp5kDRyDCLTy.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [MSVC8] libxml2 and libiconv
Thiago Macieira schrieb:
> Christian Ehrlicher wrote:
>> Apart from this, I currently stopped msvc compilation because you can't
>> do anything with the resulting apps (it crshes all over the time)
>> because we mix release and debug libs.
>
> KDE has never had that problem because none of the systems we've supported
> so far had a difference between release and debug builds.
>
> Can you explain what is different and what we have to do in order to be
> compliant?
Because MSVC is using two different msvcrt - libraries (one release and
one debug version) you can't mix debug and release libs without a crash
sooner or later. Qt introduced the debug-prefix ('d' or '_debug') to
work around this problem and we need this for kde too. I don't know any
other way to be sure to not mix the libs... :-(
Christian
signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: kdebase dashboard?
On Fri, Apr 14, 2006 at 10:24:45PM -0400, William A. Hoffman wrote: > At 11:16 AM 4/14/2006, David Faure wrote: > >On Thu, Apr 13, 2006 at 11:18:35PM -0400, Bill Hoffman wrote: > >> So, the kdelibs dashboard is looking OK now. Still some issues with > >> visual studio, but OSX, mingw, and Linux are working well. What is the > >> state of kdebase? Is it time to set up a dashboard for kdebase? > > > >Yes this would be useful; but you need to compile and install > >kdelibs4_snapshot first... > > Is kdebase supposed to work with kdelibs svn? No, not with kdelibs from trunk. That was the point of my reply. > If so, then the dashboards that build kdelibs could install the nightly > builds and then run a dashboard for kdebase > next. The dashboard would need to build kdelibs4_snapshot (from branches/work/kdelibs4_snapshot), then install it, and then build kdebase. This separation allows us to make large changes to kdelibs without propagating them immediately to all other modules; it also allows developers of those other modules to work without having to recompile kdelibs constantly. But for people who want to compile everything it means one more module to compile indeed. -- David Faure [EMAIL PROTECTED] ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [Kde-pim] Difference in compilation (Re: [STATUS] Building KDEPIM with CMake)
On Wednesday 12 April 2006 14:24, Allen Winter wrote: > On Wednesday 12 April 2006 13:27, Dirk Mueller wrote: > > 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. > > > But Dirk, with -fno-common I have no way of linking this yacc/lex generated > code. > Can we make an exception in the case of kdepim/libkholidays? > Is there a way to put back common symbols for this subdir only? > > 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. > Ok, now that I've had a few days away and the braincells have had a little rest... I can say that the fix I put in last week, using extern, is the right fix for this issue. This thread is done. Thanks for listening to my ravings, Allen -- Let's Keep the Political Talk Out of KDE PLEASE ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: How to set CXXFLAGS with CMake?
On Sunday 16 April 2006 18:18, Michael Pyne wrote: > Hi all, > > I've had a problem report from a kdesvn-build that when setting CXXFLAGS to > something like -march=i686 that CMake would complain about the '=' character. > > He also reports that setting the CFLAGS environment variable instead does > work. > > kdesvn-build passes CXXFLAGS to CMake like this right now: > > cmake -DCMAKE_CXX_FLAGS="$cxxflags" other-options... > > The cxxflags are correctly passed as one argument (i.e. no shell IFS stuff is > going on). > > Is there a preferred method to set CXXFLAGS for CMake, or am I doing the > right > thing and it's a CMake bug? The CMake version is the 20060317 snapshot. > Hi mpyne, One idea... We could introduce a new option for kdelibs/cmake/modules/FindKDE4Internal.cmake, called say CMAKE_CXX_OPT_FLAGS_RELEASE. This variable gets appended onto CMAKE_CXX_FLAGS_RELEASE. Note that it would only be used with release builds. So you'd call cmake with the extra -DCMAKE_CXX_OPT_FLAGS_RELEASE="-march=i686" Ditto for CMAKE_C_FLAGS_RELEASE -Allen -- Let's Keep the Political Talk Out of KDE PLEASE ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
KDE/kdelibs/kdeui
SVN commit 530679 by mojo: Don't use X11 includes on Windows. CCMAIL: kde-buildsystem@kde.org M +1 -1 kkeyserver.h --- trunk/KDE/kdelibs/kdeui/kkeyserver.h #530678:530679 @@ -23,7 +23,7 @@ #ifndef _KKEYSERVER_H #define _KKEYSERVER_H -#if defined Q_WS_X11 or defined Q_WS_WIN +#if defined Q_WS_X11 /*or defined Q_WS_WIN*/ #include "kkeyserver_x11.h" #elif defined Q_WS_MACX #include "kkeyserver_mac.h" ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
