Re: QString::i18n
On Tuesday 11 April 2006 14:58, Maarten Th. Mulders wrote: How to fix it, then? I'm not too familiar with C++, nor with the MSVC. you could try to build it with mingw. it uses the same compiler (gcc) as we use under linux... Regards, Maarten Th. Mulders Thiago Macieira wrote: Maarten Th. Mulders wrote: I searched in Qt sources but the headers do not have any i18n. Ideas, anyone? It's in klocale.cpp. I suspect this is brokenness of the Microsoft compiler. It doesn't understand templates very well... -- regards, Holger Schröder ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
cmake --help case sensitivity
$ cmake --help exec_program Help argument exec_program is not a CMake command. Use --help-command-list to see all commands. $ cmake --help EXEC_PROGRAM [works] Since commands are case insensitive, can --help be fixed to be case insensitive as well? Thanks. -- 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: Visual Studio 8 2005 Makefiles
-Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 7 de Abril de 2006 18:28 To: kde-buildsystem@kde.org Subject: Re: Visual Studio 8 2005 Makefiles At 11:32 AM 4/7/2006, Paulo Jorge Guedes wrote: Hi, Did anyone tried to generate makefiles for VS project? I can configure for NMake makefiles but not for Visual Studio: The error output goes attached. When checking about the compiler it can't link because it complains about opening user32.lib. This lib is in the SDK /lib dir, and it's included in CMAKE_LIBRARY_PATH and LIB envs. Like I said I have no problem when using NMake Makefiles. Can anybody reproduce this? Paulo This has to do with your installation of the free 2005 visual stuido and SDK. Did you follow these instructions: http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/ Thanks, it's working now. Paulo ___ 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: even more kio fixes for MSVC
On Wednesday 12 April 2006 01:56, Michael Drüing wrote: I should have waited with my previous mail. Here are some more fixes for kio. Thanks, committed. The authinfo.cpp is especially interesting, because it already includes sys/stat.h. However, the S_I constants are not defined when they're used. Moving the #include a few lines up fixes that. Seems like something #undef's the constants again. Very strange, because it's nothing in kdelibs that does that, so it must be in the msvc system headers? Although, you moved it -up-, not down, so I can't see how the problem would be an undef... -- 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: cmake --help case sensitivity
At 06:02 AM 4/12/2006, David Faure wrote: $ cmake --help exec_program Help argument exec_program is not a CMake command. Use --help-command-list to see all commands. $ cmake --help EXEC_PROGRAM [works] Since commands are case insensitive, can --help be fixed to be case insensitive as well? Thanks. Good point, fixed in cvs CMake. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
KDE/kdelibs/kio/kio
SVN commit 529046 by mojo: stat.h is needed for S_IRWXU and company. CCMAIL: kde-buildsystem@kde.org M +1 -0 kfileitem.cpp --- trunk/KDE/kdelibs/kio/kio/kfileitem.cpp #529045:529046 @@ -27,6 +27,7 @@ #include pwd.h #include grp.h #include sys/types.h +#include sys/stat.h #include assert.h #include unistd.h ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
KDE/kdelibs/knewstuff
SVN commit 529067 by mojo: Move KDE_DEPRECATED to the begining of the method, so it compiles on MSVC. CCMAIL: kde-buildsystem@kde.org M +1 -1 downloaddialog.h --- trunk/KDE/kdelibs/knewstuff/downloaddialog.h #529066:529067 @@ -85,7 +85,7 @@ @param category a Hotstuff data type such as korganizer/calendar */ void setCategory(const QString category); -void setType(const QString type) KDE_DEPRECATED; +KDE_DEPRECATED void setType(const QString type); /** Explicitly uses this provider list instead of the one read from ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
MSVC status
Hi, Except for the QTreeWidgetItem::itemFromIndex error it now builds until kstyles: Creating library ..\..\bin\keramik.lib and object ..\..\bin\keramik.exp keramik.obj : error LNK2019: unresolved external symbol __declspec(dllimport) p ublic: static struct KStyle::DoubleButtonOption * __cdecl KStyle::OptionBasestr uct KStyle::DoubleButtonOption,struct KStyle::Option::defaultOption(void) (__i [EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@@KS tyle@@SA [EMAIL PROTECTED]@XZ) referenced in function protected: static struct KSt yle::DoubleButtonOption const * __cdecl KStyle::extractOptionstruct KStyle::Dou bleButtonOption const *(struct KStyle::Option *) ([EMAIL PROTECTED] [EMAIL PROTECTED]@@@KStyle@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@Z) ..\..\bin\keramik.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\l ink.EXE' : return code '0x460' DoubleButtonOption is defined in kdefx so I don't understand what is causing this. There is another problem when building using the dashboard or in the VC++ IDE: sources are not generated from kidl files. This doesn't happen when building in the command line. Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Unresolved symbol: QTreeWidgetItem::itemFromIndex(QModelIndex const) const
On Wednesday 12 April 2006 15:25, William A. Hoffman wrote: At 06:53 PM 4/11/2006, Thiago Macieira wrote: I have removed the #define protected public. This means that you get a compilation error in all platforms instead. OK, so now kdelibs does not build anywhere, what now? Fixed. -- 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
linking kjsembed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, it seems to me that kjsembed should also be linked to QtUiTools.lib. Can someone change this, if I'm correct? Regards, Maarten Th. Mulders - -- The digital signature in this email can be checked with * Thunderbird: the Enigmail-extension (http://enigmail.mozdev.org/) * Outlook (Express): the GnuPG-Plugin (http://www3.gdata.de/gpg/index.html). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPRxGrlDGjB4EDkARAmrdAKCa/Y91wVqvn4WHu/4mtUmNYEw/OwCbBCBB jtnkXbp6ranN5IVhWtF0Uxs= =zX8d -END PGP SIGNATURE- ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Unresolved symbol: QTreeWidgetItem::itemFromIndex(QModelIndex const) const
At 10:57 AM 4/12/2006, David Faure wrote: On Wednesday 12 April 2006 15:25, William A. Hoffman wrote: At 06:53 PM 4/11/2006, Thiago Macieira wrote: I have removed the #define protected public. This means that you get a compilation error in all platforms instead. OK, so now kdelibs does not build anywhere, what now? Fixed. Now for the next build problem: 27[32m27[1mBuilding CXX object kio/misc/CMakeFiles/kdeinit_kio_uiserver.dir/uiserver.o27[0m /.../kdelibs-cont-src/kio/misc/uiserver.cpp:50:27: error: observer_stub.h: No such file or directory /.../kdelibs-cont-src/kio/misc/uiserver.cpp: In member function 'void UIServer::killJob(QByteArray, int)': -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Unresolved symbol: QTreeWidgetItem::itemFromIndex(QModelIndex const) const
On Wednesday 12 April 2006 17:38, William A. Hoffman wrote: At 10:57 AM 4/12/2006, David Faure wrote: On Wednesday 12 April 2006 15:25, William A. Hoffman wrote: At 06:53 PM 4/11/2006, Thiago Macieira wrote: I have removed the #define protected public. This means that you get a compilation error in all platforms instead. OK, so now kdelibs does not build anywhere, what now? Fixed. Now for the next build problem: 27[32m27[1mBuilding CXX object kio/misc/CMakeFiles/kdeinit_kio_uiserver.dir/uiserver.o27[0m /.../kdelibs-cont-src/kio/misc/uiserver.cpp:50:27: error: observer_stub.h: No such file or directory /.../kdelibs-cont-src/kio/misc/uiserver.cpp: In member function 'void UIServer::killJob(QByteArray, int)': Ah I still had it in the builddir so I didn't notice this. Fixed the include path now. -- 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: Unresolved symbol: QTreeWidgetItem::itemFromIndex(QModelIndex const) const
At 11:49 AM 4/12/2006, David Faure wrote: Ah I still had it in the builddir so I didn't notice this. Fixed the include path now. This brings up an issue. The dashboard email seems to be somewhat ignored by kde developers. I can see two reasons: 1. There have been so many errors, that it is just assumed to be always broken. 2. The messages are going to the wrong list kde-commits is mostly ignored by the developers. So, is there a better place/way to send the email about broken builds? Or, is it the hope that things will just settle down over time. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
KDE/kdelibs/kdeprint
SVN commit 529139 by mojo: Some more of the weird moving up of the stat.h include. CCMAIL: kde-buildsystem@kde.org M +1 -1 kmspecialmanager.cpp --- trunk/KDE/kdelibs/kdeprint/kmspecialmanager.cpp #529138:529139 @@ -31,9 +31,9 @@ #include klocale.h #include kdebug.h +#include sys/stat.h #include unistd.h #include sys/types.h -#include sys/stat.h KMSpecialManager::KMSpecialManager(KMManager *parent) : QObject(parent), m_mgr(parent), m_loaded(false) ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Difference in compilation (Re: [Kde-pim] [STATUS] Building KDEPIM with CMake)
On Wednesday 12 April 2006 17:55, Allen Winter wrote: On Wednesday 12 April 2006 09:52, David Faure wrote: On Wednesday 12 April 2006 15:26, Allen Winter wrote: The solution I finally committed was to hand-edit the parseholidays.c file (originally generated by yacc from parseholidays.y). I had to make the FILE *kcalin variable extern. But then kcalin is extern in both parseholidays.c and scanholidays.c. Which doesn't seem correct. Well it works since the variable is actually defined in scanholiday.c (technically under the name yyin, but there's a #define yyin kcalin) But now I checked the 3.5 branch, and there it's exactly the opposite... extern FILE *yyin in scanholiday.c and FILE *kcalin in parseholiday.c. Why was this different in trunk before your commit - that's the real question. I copied parseholiday.y, parseholiday.[c,h], and scanholiday.c from branches/3.5 into trunk. Re-ran the cmake build process and got the multiply-defined symbol error for kcalin. Ah, you are right, the symbol was defined in scanholiday.c too (without extern). In 3.5 branch I get $ nm parseholiday.o | grep kcalin 0004 C kcalin $ nm scanholiday.o | grep kcalin 0004 B kcalin man nm says: C The symbol is common. When linking, multiple common symbols may appear with the same name. With cmake I get B for both symbols, hence the multiple definition error. So this is about a difference during compilation, not during linking. In fact most kcal* symbols were C with unsermake in parseholiday.o. unsermake ran gcc with: gcc -DHAVE_CONFIG_H -I../libkholidays -I/devel/kde/src/3/kdepim-3.5/libkholidays -I.. -I/devel/kde/src/3/kdepim-3.5 -I/devel/kde/src/3/kdepim-3.5/libkdepim -I/devel/kde/inst/kde3/include -I/devel/kde/src/3/qt-copy/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -D_FILE_OFFSET_BITS=64 -std=iso9899:1990 -W -Wall -Wchar-subscripts -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline -Wformat-security -Wmissing-format-attribute -fPIC -DPIC -c /devel/kde/src/3/kdepim-3.5/libkholidays/parseholiday.c -o ../libkholidays/.libs/parseholiday.o -Wp,-MD,../libkholidays/.deps/parseholiday.TUlo cmake runs gcc with: /usr/bin/gcc -Dkholidays_EXPORTS -Wno-long-long -ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -Wmissing-format-attribute -fno-common -O2 -g -fPIC -I/devel/kde/build/4/kdepim/libkholidays -I/devel/kde/src/4/kdepim/libkholidays -I/devel/kde/src/4/kdepim/libkdepim -I/devel/kde/src/4/kdepim -I/devel/kde/build/4/kdepim -I/devel/kde/inst/kde4/include -I/devel/kde/src/4/qt-copy/include -I/devel/kde/src/4/qt-copy/include/Qt -I/devel/kde/src/4/qt-copy/mkspecs/default -I/devel/kde/src/4/qt-copy/include/QtCore -I/devel/kde/src/4/qt-copy/include/QtGui -I/devel/kde/src/4/qt-copy/include/Qt3Support -I/devel/kde/src/4/qt-copy/include/QtAssistant -I/devel/kde/src/4/qt-copy/include/QtDesigner -I/devel/kde/src/4/qt-copy/include/QtNetwork -I/devel/kde/src/4/qt-copy/include/QtOpenGL -I/devel/kde/src/4/qt-copy/include/QtSql -I/devel/kde/src/4/qt-copy/include/QtXml -I/devel/kde/src/4/qt-copy/include/QtSvg -I/devel/kde/src/4/qt-copy/include/QtTest -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_GNU_SOURCE -DQT3_SUPPORT -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DQT3_SUPPORT_WARNINGS -DKDE_DEPRECATED_WARNINGS -DHAVE_CONFIG_H=1 -c /devel/kde/src/4/kdepim/libkholidays/parseholiday.c -o libkholidays/CMakeFiles/kholidays.dir/parseholiday.o 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 ;) For context, here are the relevant lines: parseholiday.c:FILE*kcalin; scanholiday.c:#define yyin kcalin scanholiday.c:extern FILE *yyin, *yyout; scanholiday.c:FILE *yyin = (FILE *) 0, *yyout = (FILE *) 0; [don't look in svn trunk, there's a workaround now] -- David Faure -- [EMAIL PROTECTED], [EMAIL PROTECTED] KDE/KOffice developer, Qt consultancy projects Klarälvdalens Datakonsult AB, Platform-independent software solutions ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Unresolved symbol: QTreeWidgetItem::itemFromIndex(QModelIndex const) const
On Wednesday 12 April 2006 18:30, William A. Hoffman wrote: At 11:49 AM 4/12/2006, David Faure wrote: Ah I still had it in the builddir so I didn't notice this. Fixed the include path now. This brings up an issue. The dashboard email seems to be somewhat ignored by kde developers. I can see two reasons: 1. There have been so many errors, that it is just assumed to be always broken. 2. The messages are going to the wrong list kde-commits is mostly ignored by the developers. I replied to most broken build emails sent to kde-commits, but I haven't seen any for a while now... -- 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: 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
KDE/kdelibs/win/include/msvc
SVN commit 529195 by chehrlic:
instead fixing the symptoms of a problem it's better to fix the problem...
CCMAIL: kde-buildsystem@kde.org
M +1 -5 sys/stat.h
M +0 -18 unistd.h
--- trunk/KDE/kdelibs/win/include/msvc/sys/stat.h #529194:529195
@@ -32,9 +32,7 @@
extern C {
#endif
-#if !defined _STAT_H_ !defined _INC_DIRECT
-
-#define_IFMT 017 // type of file
+#define _IFMT 017 // type of file
#define_IFDIR 004 // directory
#define_IFCHR 002 // character special
#define_IFBLK 006 // block special
@@ -75,8 +73,6 @@
#defineS_ISLNK(m) (((m)_IFMT) == _IFLNK)
#defineS_ISSOCK(m) (((m)_IFMT) == _IFSOCK)
-#endif
-
KDEWIN32_EXPORT int lstat( const char *__path, struct stat *__buf);
KDEWIN32_EXPORT int lstat64( const char *__path, struct stat64 *__buf);
--- trunk/KDE/kdelibs/win/include/msvc/unistd.h #529194:529195
@@ -49,24 +49,6 @@
#defineW_OK2
#defineX_OK1
-/* + from sys/stat.h: */
-#define_IFMT 017 /* type of file */
-#define_IFDIR 004 /* directory */
-#define_IFCHR 002 /* character special */
-#define_IFBLK 006 /* block special */
-#define_IFREG 010 /* regular */
-#define_IFLNK 012 /* symbolic link */
-#define_IFSOCK 014 /* socket */
-#define_IFIFO 001 /* fifo */
-
-#defineS_ISBLK(m) (((m)_IFMT) == _IFBLK)
-#defineS_ISCHR(m) (((m)_IFMT) == _IFCHR)
-#defineS_ISDIR(m) (((m)_IFMT) == _IFDIR)
-#defineS_ISFIFO(m) (((m)_IFMT) == _IFIFO)
-#defineS_ISREG(m) (((m)_IFMT) == _IFREG)
-#defineS_ISLNK(m) (((m)_IFMT) == _IFLNK)
-#defineS_ISSOCK(m) (((m)_IFMT) == _IFSOCK)
-
#ifndef STDOUT_FILENO
#define STDOUT_FILENO 1
#endif
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: MSVC status
-Original Message- From: Paulo Jorge Guedes [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 12 de Abril de 2006 17:36 To: kde-buildsystem@kde.org Subject: RE: MSVC status There is another problem when building using the dashboard or in the VC++ IDE: sources are not generated from kidl files. This doesn't happen when building in the command line. It would be important to get some help here so we could have a meaningful MSVC dashboard (assuming anyone cares or read the dashboard email or visit http://public.kitware.com/KDE/Testing/). IIUC, dcopidl script generates a .kidl file from a dcop interface file (.h). How is the .cpp skel file is generated? This is done by dcopidl2cpp but what is calling it, kalyptus? How can I debug this, by hacking kalyptus script or skel.cpp? Paulo ___ 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)
Allen Winter wrote: But Dirk, with -fno-common I have no way of linking this yacc/lex generated code. Are both files generated by yacc and lex? The problem is that both define a symbol called kcalin: parseholiday.c:FILE*kcalin; scanholiday.c:#define yyin kcalin scanholiday.c:FILE *yyin = (FILE *) 0, *yyout = (FILE *) 0; This is wrong. They should not be the same symbol. Or, if they should be, one of the two must be changed to an extern. -- 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 pgpcOE065fXa6.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
Michael Drüing wrote: for some reason I get an error each time something links to libxml2.lib, because libxml2.lib needs iconv.lib which is not linked in automatically. I think I remember someone mentioning here on the list that MSVC doesn't do this, so I think this should be fixed in the CMake files... Like, for example, checking if a test-program that links to libxml2.lib (or xml2.lib, whichever was detected) also needs to be explicitly linked to iconv.lib (or maybe libiconv.lib) And then libxml2.lib changes its dependencies in the future, how do we cope? This is the wrong question to ask. The right question is: in which *installed* file does libxml2.lib store its dependency information? Is it the lib itself? Does the linker automatically link to the dependencies? If not, how can we extract the information from it? -- 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 pgpSYNFkXqgRq.pgp Description: PGP signature ___ 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
Re: KDE/kdelibs/kjs
On Wednesday 12 April 2006 13:21, Paulo Moura Guedes wrote:
SVN commit 528999 by mojo:
MSVC needs stdint.h from kdewin32 includes.
CCMAIL: kde-buildsystem@kde.org
M +3 -0 CMakeLists.txt
--- trunk/KDE/kdelibs/kjs/CMakeLists.txt #528998:528999
@@ -12,6 +12,9 @@
#macro_additional_clean_files( ${CMAKE_CURRENT_BINARY_DIR}/global.h )
include_directories( ${CMAKE_SOURCE_DIR}/kxmlcore ${QT_INCLUDES} )
+if(WIN32)
+ include_directories( ${KDEWIN32_INCLUDES} )
+endif(WIN32)
Somehow I think this should be done more globally, probably in
FindKDE4Internal.cmake (isn't it there already ?)
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: KDE/kdelibs/kjs
On Wednesday 12 April 2006 22:48, Alexander Neundorf wrote:
On Wednesday 12 April 2006 13:21, Paulo Moura Guedes wrote:
SVN commit 528999 by mojo:
MSVC needs stdint.h from kdewin32 includes.
CCMAIL: kde-buildsystem@kde.org
M +3 -0 CMakeLists.txt
--- trunk/KDE/kdelibs/kjs/CMakeLists.txt #528998:528999
@@ -12,6 +12,9 @@
#macro_additional_clean_files( ${CMAKE_CURRENT_BINARY_DIR}/global.h )
include_directories( ${CMAKE_SOURCE_DIR}/kxmlcore ${QT_INCLUDES} )
+if(WIN32)
+ include_directories( ${KDEWIN32_INCLUDES} )
+endif(WIN32)
Somehow I think this should be done more globally, probably in
FindKDE4Internal.cmake (isn't it there already ?)
kjs is always a bit special since it doesn't depend on the rest of kde (nor
even on qt in theory).
--
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: [MSVC8] libxml2 and libiconv
Thiago Macieira schrieb: Michael Drüing wrote: for some reason I get an error each time something links to libxml2.lib, because libxml2.lib needs iconv.lib which is not linked in automatically. I think I remember someone mentioning here on the list that MSVC doesn't do this, so I think this should be fixed in the CMake files... Like, for example, checking if a test-program that links to libxml2.lib (or xml2.lib, whichever was detected) also needs to be explicitly linked to iconv.lib (or maybe libiconv.lib) And then libxml2.lib changes its dependencies in the future, how do we cope? This is the wrong question to ask. The right question is: in which *installed* file does libxml2.lib store its dependency information? Is it the lib itself? Does the linker automatically link to the dependencies? If not, how can we extract the information from it? Afaik the import lib *only* depends on it's shread lib and nothing more. So I think Michael is using a static libxml which is wrong. 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. Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
