RE: MSYS Makefiles Generator
-Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 3 de Abril de 2006 21:22 To: kde-buildsystem@kde.org Subject: RE: MSYS Makefiles Generator At 02:46 PM 4/3/2006, Paulo Jorge Guedes wrote: -Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 3 de Abril de 2006 18:52 To: kde-buildsystem@kde.org Subject: Re: MSYS Makefiles Generator There may be some cmake variables that can be converted to unix paths that will fix the problem. This looks like it may have to do with the FindQt4.cmake changes. What version of that are you using? I have committed a fix to cvs cmake that should fix the problem. It seems it didn't :( I also have a error: `getuid' undeclared; this is declared in the kdewin32 include files. I changed my CMAKE_INCLUDE_PATH to: $ echo $CMAKE_INCLUDE_PATH C:/Program Files/kdewin32/include/mingw;C:/Program Files/kdewin32/include;D:/gnuwin32/include But I still get the error. What am I doing wrong? Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Troubles building Qt 4.1.1
Maarten Th. Mulders wrote: Hi all, as advised by David Faure, I applied the patches from trunk/qt-copy/patches to my version of Qt (4.1.1). I had applied the MSVC-patches before. Now, Qt doesn't (re)build, it exits with a linker error when linking all files in src/gui/kernel. error LNK2001: unresolved external symbol public: virtual __thiscall QActionWidgetFactory::~QActionWidgetFactory(void) (??1QActionWidgetFactory@@[EMAIL PROTECTED]) and error LNK2001: unresolved external symbol public: virtual void __thiscall QActionWidgetFactory::destroyToolBarWidget(class QWidget *) ([EMAIL PROTECTED]@@UAEXPAVQWidget@@@Z) Appearently, those two functions can't be found for some reason. Does anybody know how to fix this? Or, if not, where to ask for support? Please make sure that patch 0119 is applied correctly. It's the one that adds those. The fact that you're getting the undefined error in the first place means that the header is patched. Please check that qaction.cpp is patched too. -- 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 pgpNRsqZ3MJ5K.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: MSYS Makefiles Generator
Paulo Jorge Guedes wrote: -Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 3 de Abril de 2006 21:22 To: kde-buildsystem@kde.org Subject: RE: MSYS Makefiles Generator At 02:46 PM 4/3/2006, Paulo Jorge Guedes wrote: -Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 3 de Abril de 2006 18:52 To: kde-buildsystem@kde.org Subject: Re: MSYS Makefiles Generator There may be some cmake variables that can be converted to unix paths that will fix the problem. This looks like it may have to do with the FindQt4.cmake changes. What version of that are you using? I have committed a fix to cvs cmake that should fix the problem. It seems it didn't :( I also have a error: `getuid' undeclared; this is declared in the kdewin32 include files. I changed my CMAKE_INCLUDE_PATH to: $ echo $CMAKE_INCLUDE_PATH C:/Program Files/kdewin32/include/mingw;C:/Program Files/kdewin32/include;D:/gnuwin32/include But I still get the error. What am I doing wrong? Did you try this in a fresh build tree? It may be that the CMakeDirectoryInformation.cmake files are left with the buggy version and prevent the fixed version from running and rewriting them. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: MSYS Makefiles Generator
-Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: terça-feira, 4 de Abril de 2006 14:16 To: kde-buildsystem@kde.org Subject: RE: MSYS Makefiles Generator At 05:39 AM 4/4/2006, Paulo Jorge Guedes wrote: -Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 3 de Abril de 2006 21:22 To: kde-buildsystem@kde.org Subject: RE: MSYS Makefiles Generator At 02:46 PM 4/3/2006, Paulo Jorge Guedes wrote: -Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 3 de Abril de 2006 18:52 To: kde-buildsystem@kde.org Subject: Re: MSYS Makefiles Generator There may be some cmake variables that can be converted to unix paths that will fix the problem. This looks like it may have to do with the FindQt4.cmake changes. What version of that are you using? I have committed a fix to cvs cmake that should fix the problem. It seems it didn't :( The dashboard is using a cmake from 3/17/2006 and that does not have the changes I commited. You can see the version used by clicking on the icon that looks like a gear next to the note icon. Your build is mojo.risin.mingw right? Right. Sorry for didn't mention before but I'm not testing with the dashboard. It's a fresh updated checkout that I use to see if the problem is with the dash setup or not. I also have a error: `getuid' undeclared; this is declared in the kdewin32 include files. I changed my CMAKE_INCLUDE_PATH to: $ echo $CMAKE_INCLUDE_PATH C:/Program Files/kdewin32/include/mingw;C:/Program Files/kdewin32/include;D:/gnuwin32/include But I still get the error. What am I doing wrong? Maybe rebuild kdewin32, reinstall it, and then remove CMakeCache.txt from the build tree. Yeah, I did that (see above) but didn't work. Part of the nightly build process should be a separate build of kdewin32 and install. (did I mention that this is not a good way to do this :) ). kdewin32 installs on C:/Program Files/kdewin32. My envs are set like this: CMAKE_INCLUDE_PATH C:/Program Files/kdewin32/include/mingw;C:/Program Files/kdewin32/include;D:/gnuwin32/include CMAKE_LIBRARY_PATH C:/Program Files/kdewin32/lib; C:/Program Files/kdewin32/bin;D:/gnuwin32/lib This used to work. Don't know what the problem is. I though this was a specific problem with my dashboard setup but I got the same errors with a free build. Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: MSYS Makefiles Generator
At 10:56 AM 4/4/2006, Paulo Jorge Guedes wrote: Right. Sorry for didn't mention before but I'm not testing with the dashboard. It's a fresh updated checkout that I use to see if the problem is with the dash setup or not. Make sure you start from an empty build tree. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: MSYS Makefiles Generator
-Original Message- From: Brad King [mailto:[EMAIL PROTECTED] Sent: terça-feira, 4 de Abril de 2006 14:37 To: kde-buildsystem@kde.org Subject: Re: MSYS Makefiles Generator Did you try this in a fresh build tree? It may be that the CMakeDirectoryInformation.cmake files are left with the buggy version and prevent the fixed version from running and rewriting them. Yes. Same error: d:/kde/kdewin32-build/CMakeFiles/CMakeDirectoryInformation.cmake:13: syntax error, unexpected cal_ERROR, expecting $end (4), when parsing string D:\downloads\qt-win-opensource-src-4.1.1\mkspecs/default CMake Error: Target DependInfo.cmake file not found CMake Error: Directory Information file not found Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: MSYS Makefiles Generator
-Original Message- From: Paulo Jorge Guedes [mailto:[EMAIL PROTECTED] Sent: terça-feira, 4 de Abril de 2006 16:28 To: kde-buildsystem@kde.org Subject: RE: MSYS Makefiles Generator -Original Message- From: Brad King [mailto:[EMAIL PROTECTED] Sent: terça-feira, 4 de Abril de 2006 14:37 To: kde-buildsystem@kde.org Subject: Re: MSYS Makefiles Generator Did you try this in a fresh build tree? It may be that the CMakeDirectoryInformation.cmake files are left with the buggy version and prevent the fixed version from running and rewriting them. Yes. Same error: d:/kde/kdewin32-build/CMakeFiles/CMakeDirectoryInformation.cmake:13: syntax error, unexpected cal_ERROR, expecting $end (4), when parsing string D:\downloads\qt-win-opensource-src-4.1.1\mkspecs/default CMake Error: Target DependInfo.cmake file not found CMake Error: Directory Information file not found Well, I renamed gnu32 and mingw unistd.h files and now it looks for the right unistd.h which has getuid() and friends declared. It seems that CMAKE_INCLUDE_PATH is ignored... However, I get an error when including this file: 24: #include ../include/unistd.h This include doesn't exist. Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: MSYS Makefiles Generator
At 12:01 PM 4/4/2006, Paulo Jorge Guedes wrote: Well, I renamed gnu32 and mingw unistd.h files and now it looks for the right unistd.h which has getuid() and friends declared. It seems that CMAKE_INCLUDE_PATH is ignored... CMAKE_INCLUDE_PATH is used to find header files. It does not add an actual -I to the build. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: MSYS Makefiles Generator
Paulo Jorge Guedes schrieb: -Original Message- From: William A. Hoffman [mailto:[EMAIL PROTECTED] Sent: terça-feira, 4 de Abril de 2006 17:09 To: kde-buildsystem@kde.org Subject: RE: MSYS Makefiles Generator At 12:01 PM 4/4/2006, Paulo Jorge Guedes wrote: Well, I renamed gnu32 and mingw unistd.h files and now it looks for the right unistd.h which has getuid() and friends declared. It seems that CMAKE_INCLUDE_PATH is ignored... CMAKE_INCLUDE_PATH is used to find header files. It does not add an actual -I to the build. I'm a little confused. The right unistd.h is in C:\Program Files\kdewin32\include\mingw. That file includes a ../include/unistd.h that doesn't exist. The order of include paths should be set by me? I haven't had this problem before, don't know what caused it and if it should be corrected on my side or not (the missing ../include/unistd.h seems like a real problem). The unistd.h you're searching for is in your programm dir/MinGW/include Christian ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: MSYS Makefiles Generator
At 11:28 AM 4/4/2006, Paulo Jorge Guedes wrote:
-Original Message-
From: Brad King [mailto:[EMAIL PROTECTED]
Sent: terça-feira, 4 de Abril de 2006 14:37
To: kde-buildsystem@kde.org
Subject: Re: MSYS Makefiles Generator
Did you try this in a fresh build tree? It may be that the
CMakeDirectoryInformation.cmake files are left with the buggy version
and prevent the fixed version from running and rewriting them.
Yes. Same error:
d:/kde/kdewin32-build/CMakeFiles/CMakeDirectoryInformation.cmake:13:
syntax error, unexpected cal_ERROR, expecting $end (4), when parsing string
D:\downloads\qt-win-opensource-src-4.1.1\mkspecs/default
CMake Error: Target DependInfo.cmake file not found
CMake Error: Directory Information file not found
OK, so I fixed this in CVS CMake. However, it can fix it in kde with this
change:
In FindQt4.cmake: (convert the path for mkspecs to unix style path)
IF (NOT QT_MKSPECS_DIR)
EXEC_PROGRAM( ${QT_QMAKE_EXECUTABLE}
ARGS -query QMAKE_MKSPECS
OUTPUT_VARIABLE qt_mkspecs_dir )
# convert the path to unix style path
STRING(REGEX REPLACE / qt_mkspecs_dir ${qt_mkspecs_dir})
SET(QT_MKSPECS_DIR ${qt_mkspecs_dir} CACHE PATH The location of the Qt
mkspecs)
ENDIF (NOT QT_MKSPECS_DIR)
The fix in cmake allows include directories to be windows style, and converts
them automatically in the include_directories command.
-Bill
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
QT_LSTAT
Hi, There is an unguarded use of QT_LSTAT in kdecore/kstandarddirs.cpp:727: int res = QT_LSTAT(link, stat_buf); This define is not available on win32-g++. Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: QT_LSTAT
Paulo Jorge Guedes schrieb: Hi, There is an unguarded use of QT_LSTAT in kdecore/kstandarddirs.cpp:727: int res = QT_LSTAT(link, stat_buf); This define is not available on win32-g++. Yes, I know. We discussed this on the list already. I'll fix it until the next kdelibs_snapshot Christian ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: making sure the right libraries are found
Brad King wrote: Matt Rogers wrote: When attempting to build kdevelop with an older version of the installed library in the prefix, cmake/make/ld/whatever doesn't seem to pick up the right library to use. Rather than using the library I just built, it uses the previously installed one. Here's the output from make: Linking CXX executable kdevassistant [snip] -L/home/kde/installs/trunk/lib -L/home/kde/trunk/build/KDE/kdevelop/lib -L/home/qt/4.1/lib -L/usr/local/lib -L/lib [snip] -Wl,-rpath,/home/kde/installs/trunk/lib:/home/kde/trunk/build/KDE/kdevelop/lib:/home/qt/4.1/lib:/usr/local/lib:/lib [snip] How do I get this fixed? Clearly the link directories are listed in the wrong order. This is likely a CMake issue which I'll investigate. It is supposed to automatically compute a safe order but there is a bug in that it doesn't take into account libraries that will be present after the project builds. I don't know why no one has encountered this before. This is now fixed in CVS CMake. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: making sure the right libraries are found
On Tuesday 04 April 2006 20:43, Brad King wrote: Brad King wrote: Matt Rogers wrote: When attempting to build kdevelop with an older version of the installed library in the prefix, cmake/make/ld/whatever doesn't seem to pick up the right library to use. Rather than using the library I just built, it uses the previously installed one. Here's the output from make: Linking CXX executable kdevassistant [snip] -L/home/kde/installs/trunk/lib -L/home/kde/trunk/build/KDE/kdevelop/lib -L/home/qt/4.1/lib -L/usr/local/lib -L/lib [snip] -Wl,-rpath,/home/kde/installs/trunk/lib:/home/kde/trunk/build/KDE/kdevelo p/lib:/home/qt/4.1/lib:/usr/local/lib:/lib [snip] How do I get this fixed? Clearly the link directories are listed in the wrong order. This is likely a CMake issue which I'll investigate. It is supposed to automatically compute a safe order but there is a bug in that it doesn't take into account libraries that will be present after the project builds. I don't know why no one has encountered this before. This is now fixed in CVS CMake. Matt, can you please check whether this works for you ? 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: make -j4 broken again?
At 02:47 PM 4/4/2006, David Faure wrote:
On Tuesday 04 April 2006 20:40, William A. Hoffman wrote:
I think the parallel build is broken again.
There are random failures on this dashboard:
http://public.kitware.com/KDE/Testing/Sites/matt.rogers.name/Linux-Archlinux-gcc4.0.3/20060404-0100-Nightly/BuildError.html
It uses make -j4 for the build. The other dashboard on dash17 is working
fine for
the same build, and it does not use parallel builds.
Right; this looks like a missing dependency on settings.h, which is a
generated header file
(generated from settings.kcfgc using kconfig_compiler.
So this would be a bug in KDE4_ADD_KCFG_FILES, from
kdelibs/cmake/modules/KDE4Macros.cmake
Hmm. Would this fix it?
--- KDE4Macros.cmake(revision 526070)
+++ KDE4Macros.cmake(working copy)
@@ -128,6 +128,7 @@ MACRO (KDE4_ADD_KCFG_FILES _sources)
SET_SOURCE_FILES_PROPERTIES(${_header_FILE} PROPERTIES GENERATED TRUE)
QT4_GENERATE_MOC(${_header_FILE} ${_moc_FILE} )
MACRO_ADD_FILE_DEPENDENCIES(${_src_FILE} ${_moc_FILE} )
+ MACRO_ADD_FILE_DEPENDENCIES(${_moc_FILE} ${_header_FILE} )
set(${_sources} ${${_sources}} ${_src_FILE})
All generated header files now need to be part of the sources for the target
they are part of.
So, maybe this would fix it:
set(${_sources} ${${_sources}} ${_src_FILE} ${_header_FILE})
-Bill
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make -j4 broken again?
At 02:55 PM 4/4/2006, Alexander Neundorf wrote: Brad suggested to add a second custom command which has as output the second generated file, no command, and depends on the first generated file. I just committed this, but cannot test it very good with one processor only. Well, if it works, it should fix the dashboard, and we will know in the morning. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: making sure the right libraries are found
On Tue, Apr 04, 2006 at 02:43:39PM -0400, Brad King wrote: Brad King wrote: Matt Rogers wrote: When attempting to build kdevelop with an older version of the installed library in the prefix, cmake/make/ld/whatever doesn't seem to pick up the right library to use. Rather than using the library I just built, it uses the previously installed one. Here's the output from make: Linking CXX executable kdevassistant [snip] -L/home/kde/installs/trunk/lib -L/home/kde/trunk/build/KDE/kdevelop/lib -L/home/qt/4.1/lib -L/usr/local/lib -L/lib [snip] -Wl,-rpath,/home/kde/installs/trunk/lib:/home/kde/trunk/build/KDE/kdevelop/lib:/home/qt/4.1/lib:/usr/local/lib:/lib [snip] How do I get this fixed? Clearly the link directories are listed in the wrong order. This is likely a CMake issue which I'll investigate. It is supposed to automatically compute a safe order but there is a bug in that it doesn't take into account libraries that will be present after the project builds. I don't know why no one has encountered this before. This is now fixed in CVS CMake. -Brad Thanks, will test. -- Matt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Fwd: Re: Can't compile kdelibs with cmake
Something going wrong in the Qt4 detection? **Unknown***1 looks fun :) -- Forwarded Message -- Subject: Re: Can't compile kdelibs with cmake Date: Tuesday 04 April 2006 22:08 From: Eduard Bachmakov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Am Dienstag, 4. April 2006 20:09 schrieb David Faure: On Tuesday 04 April 2006 17:04, Eduard Bachmakov wrote: I just don't understand why it doesn't work... Here's the output: [EMAIL PROTECTED]:~/src/kde$ ls arts kdebase kdelibs-build kdesupport l10n qt-copy build kdelibs kdenonbeta kdewebdev log successfully-built [EMAIL PROTECTED]:~/src/kde$ cd kdelibs-build [EMAIL PROTECTED]:~/src/kde/kdelibs-build$ cmake ../kdelibs kdelibs requires an out of source build. Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there. You probably need to remove CMakeCache.txt from kdelibs; otherwise launching cmake from elsewhere still launches cmake in the srcdir like before. Thank you very much! The cache was the problem. But now I have a new one: [EMAIL PROTECTED]:~/src/kde/build/kdelibs$ cmake ../../kdelibs -- 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 -- This is a SVN repository -- Using Buildname: Linux-c++ CMake Error: Error in cmake code at /home/kdedev/src/kde/kdelibs/cmake/modules/FindQt4.cmake:203: MATH cannot parse the expression: **Unknown***1 + **Unknown***100 + **Unknown**: syntax error, unexpected exp_TIMES, expecting exp_OPENPARENT or exp_NUMBER (1) Warning: QT_QMAKE_EXECUTABLE reported QT_INSTALL_LIBS as **Unknown** Warning: **Unknown** does NOT exist, Qt must NOT be installed correctly. Qt libraries, includes, moc, uic or/and rcc NOT found! -- Configuring done [EMAIL PROTECTED]:~/src/kde/build/kdelibs$ All that I understand is that there is a parsing error... Does that mean it is bad made (probably bad english :-) I mean an error in the code? Or can't it find my Qt-copy? But I'm sure the path to it is in the .bash_profile... Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe --- -- 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: Fwd: Re: Can't compile kdelibs with cmake
On Tuesday 04 April 2006 22:17, David Faure wrote:
Something going wrong in the Qt4 detection? **Unknown***1 looks fun
:)
Actually the error message was 100% clear, although it looks quite obscure:
It's this line:
MATH(EXPR found_vers ${found_qt_major_vers}*1 +
${found_qt_minor_vers}*100 + ${found_qt_patch_vers})
and each of the found_qt_xxx_vers was set to **Unknown**, since this is what
Qt3 qmake returns on the query.
I committed a fix to trunk.
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
kdeui/kglobalaccel_win.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, when building, kglobalaccel.h can't find kdeui/kglobalaccel_win.h. Indeed, this file does not exist. KDE 3.4 has it, but it uses Qt3. How to solve this problem? Kind 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 iD8DBQFEMu0crlDGjB4EDkARAlb4AKCs2QoXNpZdxPJJi3ojuTrIt5YdZgCfRJ8P Oqr8Xp+ah5acXxC/jIgsXpk= =lzaj -END PGP SIGNATURE- ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: kdeui/kglobalaccel_win.h
On 4/4/06, Maarten Th. Mulders [EMAIL PROTECTED] wrote: when building, kglobalaccel.h can't find kdeui/kglobalaccel_win.h. Indeed, this file does not exist. KDE 3.4 has it, but it uses Qt3. How to solve this problem? I think cmake was scanning the dependencies of kglobalaccel.cpp and thought it might need kglobalaccel_win.h since it was included inside an #ifdef, even though it didn't exist anymore. I removed it from kglobalaccel.cpp and it built fine. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
kdeui/kglobalaccel_win.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, again, during kdeui/kglobalaccel.cpp build it stops because it can't find kaccelbase.h. kdeui/kglobalaccel.cpp includes kdecore/kglobalaccel_emb.h. So does kdeui try to build against QtEmbedded under Windows? That would seem quite strange to me... Kind 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 iD8DBQFEMvcHrlDGjB4EDkARAh6iAJ0doT6lk3huqGkasm9EKa/FAvnipgCguLNs RQRj/GHidEmkVFLl2H0QjgI= =6faS -END PGP SIGNATURE- ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
