D24841: Use modern way to set the C/CXX standad

[Christian Ehrlicher]

chehrlic added a comment.


  I would also use CMAKE_CXX_STANDARD_REQUIRED to make sure the compiler 
actually *can* c++11, otherwise the flag is only added when the compiler 
supports it. Should not make much difference nowadays but since it's in ECM...

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D24841

To: vonreth, dfaure, cullmann
Cc: chehrlic, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, 
bencreasy, michaelh, ngraham, bruns

D23789: RFC: Add ECMGenerateExportHeaders, for improved handling of deprecated API

[Christian Ehrlicher]

chehrlic added a comment.


  In D23789#538985 , @kossebau wrote:
  
  > >> - why has all Qt code not yet been adapted to 
QT_DEPRECATED_VERSION/QT_DEPRECATED_VERSION_X, are there places where those 
macros should not be used, but the version-less ones?
  > > 
  > > Because noone wanted to do the work and it was added late in the Qt5 
lifetime -> A lot of stuff was deprecated for a long time already (in Qt4 
times) and there is was a replacement since Qt5.0.0 so the macro was not needed 
(even though a lot of people got very angry about it). I added it for some new 
signals which created a lot of discussion since the old ones are widely used.
  >
  > Can you point to those discussions? Would be curious to learn what people's 
thought are.
  
  
  https://lists.qt-project.org/pipermail/development/2019-March/035343.html
  
  It's most likely a discussion when a deprecated / replaced function should 
really create a warning (esp. when the replacement was just recently added) and 
when the function should be removed completely - should a function deprecated 
in Qt5 really be removed in Qt6 or wait for Qt7 or don't remove it at all.
  
  > 
  > 
  >>> - why did you go for both QT_DEPRECATED_VERSION & 
QT_DEPRECATED_VERSION_X, are there places where no message will be wanted?
  >> 
  >> Just for consistency - we've QT_DEPRECATED and QT_DEPRECATED_X but I think 
QT_DEPRECATED should be deprecated by itself. I hope no reviewer will accept a 
QT_DEPRECATED anymore.
  > 
  > So you would also think that message-less variants will not be needed I 
understand. Okay. From what I tested with experimentally deploying the macros 
on some KF modules I almost always could add a useful message, so running short 
of reasons for keeping a message-less variant :)
  
  I think it should be enough to have one macro nowadays :)

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D23789

To: kossebau
Cc: chehrlic, dfaure, cgiboudeaux, kde-frameworks-devel, kde-buildsystem, 
LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns

D23789: RFC: Add ECMGenerateExportHeaders, for improved handling of deprecated API

[Christian Ehrlicher]

chehrlic added a comment.


  In D23789#536338 , @kossebau wrote:
  
  > Actual questions I have:
  >
  > - why is QT_DEPRECATED_WARNINGS_SINCE not officially documented? like, any 
plans to change that macro to something else?
  
  
  Just forgot it (and also the reviewers) I would guess. There is no plan to 
change it, at least none I'm aware of. I'm looking for an automatic generation 
of this macro. Since Qt6 switches to CMake I can maybe borrow some stuff from 
you ;)
  
  > - why has all Qt code not yet been adapted to 
QT_DEPRECATED_VERSION/QT_DEPRECATED_VERSION_X, are there places where those 
macros should not be used, but the version-less ones?
  
  Because noone wanted to do the work and it was added late in the Qt5 lifetime 
-> A lot of stuff was deprecated for a long time already (in Qt4 times) and 
there is was a replacement since Qt5.0.0 so the macro was not needed (even 
though a lot of people got very angry about it). I added it for some new 
signals which created a lot of discussion since the old ones are widely used.
  
  > - why did you go for both QT_DEPRECATED_VERSION & QT_DEPRECATED_VERSION_X, 
are there places where no message will be wanted?
  
  Just for consistency - we've QT_DEPRECATED and QT_DEPRECATED_X but I think 
QT_DEPRECATED should be deprecated by itself. I hope no reviewer will accept a 
QT_DEPRECATED anymore.
  
  The main problem with the macro is that you have to create a new one for each 
version so it will become lengthy. But I could not find a better solution 
somewhere - in the end it's only macro magic from the 80s... :(
  But for a library such a macro should be mandatory - your blog post explains 
the problem very good.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D23789

To: kossebau
Cc: chehrlic, dfaure, cgiboudeaux, kde-frameworks-devel, kde-buildsystem, 
LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns

Re: Missing configure checks for #cmakedefine

[Christian Ehrlicher]

Thiago Macieira schrieb:
 Lubos Lunak wrote:
 At least looking at generated
 kdebase/workspace/config-workspace.h it has a couple of #undef's for
 things that obviously are present (e.g. unistd.h).
 
 unistd.h is not present on Windows (it's not a Unix system). But workspace 
 is not meant to compile on Windows anyways...
 
:)
Workspace does compile on windows due to the work of Saro and Brandon 
(afaik plasma.exe also works - at least it starts).


Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: maco_optional_find_package magic

[Christian Ehrlicher]

Alexander Neundorf schrieb:
 On Friday 13 March 2009, Jeff Mitchell wrote:
 ...
 If you don't mind, here's a CMakeLists.txt and the corresponding
 FindTaglibExtras.cmake...can you see if you can spot why this might be
 happening?

 http://websvn.kde.org/trunk/extragear/multimedia/amarok/CMakeLists.txt?revi
 sion=938768view=markup
 http://websvn.kde.org/trunk/extragear/multimedia/amarok/cmake/modules/FindT
 aglibExtras.cmake?revision=938775view=markup

 Note that in FindTaglibExtras.cmake I've expanded some macros and pasted
 them in here...this is on purpose, and not really worth getting into in
 this forum, 
 
 Yes, it is.
 FindPackageHandleStandardArgs.cmake comes with cmake and should be usable. 
 Please let us know which problems you have with it.
 
 Beside that, it looks quite ok (the expanded macros don't make reading it 
 easier).
 I'd suggest you add some debug output using message(STATUS ...) to see what's 
 going on. Or you replace the two FATAL_ERROR with STATUS to see why it's 
 failing.
 
Shouldn't it be TaglibExtras_FIND_REQUIRED and not 
Taglib-Extras_FIND_REQUIRED ?

Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FindBoostPython.cmake in kdeedu

[Christian Ehrlicher]

 Von: Pino Toscano
 Hi,
 
 I am the author of that module.
 
  while we're disussing the FindBoost.cmake - why is there a special
  FindBoostPython.cmake in kdeedu? Isn't this handled within FindBost?
 
 No, they are not the same thing.
 FindBoostPython.cmake looks for a valid boost+python combination, ie the
 right 
 python version for a boost version. Note that does not mean picking the
 first 
 boost found with the first python found.
 
Thx for the clarification. I just stumbled of this module because it also 
doesn't know anything about 1.37.

Christian
-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

FindBoostPython.cmake in kdeedu

[Christian Ehrlicher]

Hi,

while we're disussing the FindBoost.cmake - why is there a special
FindBoostPython.cmake in kdeedu? Isn't this handled within FindBost?


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Patch for KDE4Macros to use extra target on Windows

[Christian Ehrlicher]

Matthias Kretz schrieb:

On Friday 18 July 2008 23:38:45 Brad King wrote:

Matthias Kretz wrote:

attached is a patch to use the new automoc macro which adds a new target
per default on Windows.

Can someone point me to discussion of the original problem, please?


I think most of this was in german and private mail. So here's a summary:

I changed the automoc4 invocation (ADD_CUSTOM_COMMAND) to only depend on one 
file (i.e. target_automoc.cpp.files). I wanted to achieve that automoc4 gets 
called unconditionally, but without creating a new target. That's why a run of 
automoc4 now touches the file it depends on, one second after it touches its 
output file.
- With that make does what I want: execute automoc4 once per target on every 
call to make. If automoc4 decides there's nothing to do it doesn't touch any 
files and so make decides not to recompile the output file of automoc4.
- nmake seems to behave different in the last point: it thinks that if the 
output of automoc4 is a source file and automoc4 got called it has to 
recompile that source file, no matter whether automoc4 changed the timestamp 
or not. IIUC nmake internally updates the timestamp of the output source file 
and doesn't even look whether that corresponds with what happened on the 
filesystem.



Correct. You can see this when running nmake in verbose mode.


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Patch for KDE4Macros to use extra target on Windows

[Christian Ehrlicher]

Matthias Kretz schrieb:

Hi,

attached is a patch to use the new automoc macro which adds a new target per 
default on Windows.


Please let me know if that is what you want/need and whether I should commit 
this.



The patch doesn't look correct to me:

@@ -672,7 +679,11 @@

   target_link_libraries(${_target_NAME} ${QT_QTMAIN_LIBRARY} 
kdeinit_${_target_NAME})

else(WIN32)
-  kde4_handle_automoc(kdeinit_${_target_NAME} _SRCS)
+  if(WIN32)
+ add_automoc4_target(kdeinit_${_target_NAME}_automoc _SRCS)
+  else(WIN32)
+ automoc4(kdeinit_${_target_NAME} _SRCS)
+  endif(WIN32)


here we're already in the !WIN32 part so the above has no effect for 
WIN32 at all.



Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Patch for KDE4Macros to use extra target on Windows

[Christian Ehrlicher]

Thiago Macieira schrieb:
 Matthias Kretz wrote:
 - With that make does what I want: execute automoc4 once per target on
 every call to make. If automoc4 decides there's nothing to do it
 doesn't touch any files and so make decides not to recompile the output
 file of automoc4.
 
 So you have basically the rule:
 
 target: source
   automoc4 -o target source
 
 and even if automoc4 is run, mtime(source)  mtime(target) ?
 
 Since I don't think that makes sense, I must have misunderstood.
 
 Also note that Windows has a 2-second resolution for mtimes. One second 
 after may produce the same timestamp.
 
Here the log:

Mo, Mai 19 2008 20:34:57   temp_automoc.cpp.files
Mo, Mai 19 2008 20:34:57 temp_automoc.cpp
automoc called
automoc exited
Mo, Mai 19 2008 20:33:43 CMakeFiles\temp.dir\flags.make
Mo, Mai 19 2008 21:23:26 temp_automoc.cpp
Mo, Mai 19 2008 20:50:46   CMakeFiles\temp.dir\temp_automoc.obj


automoc did not touch the file - the timestmp for temp_automoc.cpp after 
automoc called is just an internal timestamp - it's neither mtime nor 
atime nor any other one.


Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Patch for KDE4Macros to use extra target on Windows

[Christian Ehrlicher]

Matthias Kretz schrieb:

Hi,

attached is a patch to use the new automoc macro which adds a new target per 
default on Windows.


Please let me know if that is what you want/need and whether I should commit 
this.



Imho it's only needed for msvc - mingw doesn't need this hack.

I'll test it this weekend.


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Solid example break kde4 bootstrap

[Christian Ehrlicher]

Hi,

The solid examples are searching for kde4:

find_package(KDE4 REQUIRED)


This fails when we're in bootstrap mode (which I am everytime when 
building binary packages because I start from a clean dir...)


I'll try to use kdelibs_SOURCE_DIR like it's done in 
FindKDE4Internal.cmake but don't know if this is the correct solution...




Christian

btw: cmake 2.4.8 did not told me where the error comes from. I had to 
use the '--debug-output' - switch




signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: recent KDE buildsystem changes that affect OSX?

[Christian Ehrlicher]

Benjamin Reed schrieb:
 On Tue, Apr 15, 2008 at 1:26 PM, Alexander Neundorf [EMAIL PROTECTED] wrote:
 
  Does it now also work with Brads fix and without local modifications ?
 
 Hm, nope.  With CMake CVS as of Apr 15 14:10 EST, I still get the
 error cmake'ing kdebase:
 
 CMake Error at apps/kwrite/CMakeLists.txt:6 (install):
   install TARGETS given no BUNDLE DESTINATION for MACOSX_BUNDLE executable
   target kwrite.
 
Why not add your fix for cmake 2.6 only?


Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: recent KDE buildsystem changes that affect OSX?

[Christian Ehrlicher]

Benjamin Reed schrieb:
 I've not had a chance to do any building of KDE stuff for a month or
 so, and I'm trying to get caught up.  I've installed the latest CMake
 release candidate (2.6.0-rc8) and have started building, and it looks
 like something deep in our macros has changed recently, I'm now unable
 to build basically anything above kdelibs.
 
 I get a whole ton of errors like this:
 
 CMake Error at runtime/kcmshell/CMakeLists.txt:9 (install):
   install TARGETS given no BUNDLE DESTINATION for MACOSX_BUNDLE executable
   target kcmshell4.
 
 
 First, on Mac OS X, bundle has 2 meanings, it's a general term for
 directories of resources (ie Foo.app/Contents/blah
 Foo.framework/{Headers,Resources,Version}) and also for a loadable
 module library.
 
 My suspicion is that this is the latter, not the former, but I wanted
 to confirm.
 
 Is this just a cmake 2.6 issue?  Or has something changed in the way
 some of the base kdelibs/etc. macros have changed since I last tried
 to build?
 
Looks like a 2.6 issue - it's much stricter than 2.4
Maybe you've to add something in FindKDE4Internal.cmake / 
INSTALL_TARGETS_DEFAULT_ARGS


HTH
Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Fwd: [quanta-devel] Unable build kdewebdev in trunk after windows related build system

[Christian Ehrlicher]

 Von: Andras Mantia
 Hi,
 
  does anyone have an idea what is wrong here?
 

svn up kdelibs - this was added some weeks ago and is needed to get the correct 
install locations on windows


Christian
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION

[Christian Ehrlicher]

Alexander Neundorf schrieb:
 On Saturday 16 February 2008, Christian Ehrlicher wrote:
 Alexander Neundorf schrieb:
 ...
 Comments ?
 No :)

 Just let us know when you checked it in as it breaks windows install.
 
 Can you do this and at the same time fix at least kdelibs ?
 
ok, done for kdelibs, kdepimlibs, kdebase-runtime, kdebase-apps, kdeedu 
and kdebase.

I just noticed that we maybe have a problem in kdepimlibs because it 
should also be compileable with kde4.0 - but think this can be fixed 
somehow. Do we have a kde version check ?


Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION

[Christian Ehrlicher]

Alexander Neundorf schrieb:
 On Thursday 14 February 2008, Alexander Neundorf wrote:
 Hi,

 On Thursday 14 February 2008, Christian Ehrlicher wrote:
 Hi,

 following the discussion in 'Re: Getting rid of the LIB_INSTALL_DIR hack
 on windows' (http://lists.kde.org/?t=12001561931r=1w=2) I created
 a patch which introduces a new var KDE4_LIB_DESTINATION.
 ...
 Next option:
 We could also add
 set(INSTALL_TARGET_DEFAULT_ARGUMENTS RUNTIME DESTINATION bin COMPONENT User
  LIBRARY DESTINATION lib COMPONENT User
  ARCHIVE DESTINATION lib COMPONENT
 Devel )

 and then do
 install(TARGETS konsole kdecore kdeui ${INSTALL_TARGETS_DEFAULT_ARGUMENTS})

 Later on this could be extended once we require (or can optionally use, not
 sure about that) CMake 2.6 which supports library frameworks on OSX, they
 need even more locations.
 
 I think I prefer this option. It works with cmake 2.4.5 and we will be able 
 to 
 extend it later on. It kind of slightly breaks source compatibility on 
 Windows, but since we don't have an official release there this is no 
 problem.
 A patch for this is attached. If we agree on this, I'd prefer if one of the 
 windows developers could apply it, after he made sure installing works 
 correctly on his system.
 
 Comments ?
 
No :)

Just let us know when you checked it in as it breaks windows install.


Thx,
Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION

[Christian Ehrlicher]

Alexander Neundorf schrieb:
 On Saturday 16 February 2008, Christian Ehrlicher wrote:
 Alexander Neundorf schrieb:
 ...
 Comments ?
 No :)

 Just let us know when you checked it in as it breaks windows install.
 
 Can you do this and at the same time fix at least kdelibs ?
 
Ok, I'll add it during the next week.


Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Getting rid of the LIB_INSTALL_DIR hack on windows

[Christian Ehrlicher]

Alexander Neundorf schrieb:
 On Tuesday 15 January 2008, Alexander Neundorf wrote:
 On Saturday 12 January 2008, Ralf Habacker wrote:
 Michael Pyne schrieb:
 On Saturday 12 January 2008, Christian Ehrlicher wrote:
 ...
 Especially since it documents
 the intent better (i.e. use this for libraries, not for anything else).

 Then we could switch libraries to use install_kde4_library() and leave
 the rest alone.
 Because there are already kde4_... macros, i suggest to use
 kde4_install_library() as macro name
 If we really want that (I object, will discuss later), the name would have
 to start with KDE4_ .
 I'm currently exchanging emails with the cmake developers, so for now
 please don't commit any changes.
 
 Ok, if we can come up with a patch we can have something like the following 
 in 
 cmake 2.6 (i.e. maybe for KDE 4.2):
 
 install(TARGETS kfoo kbar USE_PROPERTIES)
 
 Then everything related to the targets kfoo and kbar (dll, lib, but also 
 associated headers and resource files) will be installed to their destination 
 directories. These directories will be set per target using 
 set_target_properties(), which can be hidden in KDE in 
 KDE4_ADD_EXECUTABLE/LIBRARY/PLUGIN().
 If you have a better suggestion instead of USE_PROPERTIES let me know (e.g. 
 USE_TARGET_PROPERTIES).
 
Looks fine.
maybe

install(TARGETS kfoo kbar USE_PROPERTIES foo)

where foo contains all informations about the install locations?



Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Getting rid of the LIB_INSTALL_DIR hack on windows

[Christian Ehrlicher]

Hi,

I know we discussed this already, but I'm very unhappy with the current
solution.
The problem is (for all who don't remember) that we want to install the
shared libs into /bin on windows. When we install the shared libs into
/lib, we've to add an entry to the PATH env variable. Also it's not the
normal way to install shared libs in another location than the
executable - it would just confuse the user.

Because of this a hack for LIB_INSTALL_DIR was added:
set(LIB_INSTALL_DIR  lib${LIB_SUFFIX}
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib${LIB_SUFFIX}
ARCHIVE DESTINATION lib${LIB_SUFFIX}  )

This works fine until someone uses LIB_INSTALL_DIR in another context -
e.g. to install additional files, see kdepimlibs/gpgme++:

install(
 FILES
 ${CMAKE_CURRENT_BINARY_DIR}/GpgmeppConfig.cmake
 ${CMAKE_CURRENT_BINARY_DIR}/GpgmeppLibraryDepends.cmake
 DESTINATION
 ${LIB_INSTALL_DIR}/gpgmepp )



Therefore I want to change all CMakeLists.txt from

install(TARGETS foo DESTINATION ${LIB_INSTALL_DIR} )

to

install(TARGETS foo RUNTIME DESTINATION ${BIN_IINSTALL_DIR}
LIBRARY DESTINATION ${LIB_INSTALL_DIR}
ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
)

An additional macro install_kde_library() would work as well.

I don't see a problem to add those three lines as it does not affect
linux/unix and when someone forgets to add them it doesn't hurt either -
we'll notice that something is wrong when we try to start an app on windows.
Leaving the macro as it is now just gives us weird cmake errors and
we've to find a hack to work around the usage of LIB_INSTALL_DIR in the
concerning cmake scripts.



Any objections?
Christian





signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [CMake] Problem with to long path names on win32

[Christian Ehrlicher]

Brad King schrieb:

Christian Ehrlicher wrote:

Hi,

I currently can't compile kdebase/konqueror because the paths exceeds
the max path length:

D:\kde-msvc\tmp\kdebase-beta3-3.94.1.20071011\work\kdebase\apps\konqueror\sidebar\trees\konq_sidebartreetoplevelitem.cpp
: fatal error C1083: Datei (vom Compiler generiert) kann nicht geöffnet
werden:
apps/konqueror/sidebar/trees/bookmark_module/CMakeFiles/konq_sidebartree_bookmarks.dir/__/__/__/__/__/__/kdebase/apps/
konqueror/sidebar/trees/konq_sidebartreetoplevelitem.obj: No such file
or directory

Any idea how to fix this problem? I already shortened the paths but
they're still to long... :(


CMake HEAD (in CVS) uses a much better policy to determine path names to
reduce the cases in which the long names are encountered.  It also has a
way to automatically replace long path names with short ones in a unique
manner.  Unfortunately the changes are too extensive to port to the 2.4
release branch.


Thx, I'll try cmake head.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Find_Library_Ex for msvc

[Christian Ehrlicher]

(KDEWIN32_LIBRARY_RELEASE)
- set(KDEWIN32_LIBRARY ${KDEWIN32_LIBRARY_DEBUG})
-   endif(KDEWIN32_LIBRARY_RELEASE)
-endif(MSVC)
-  
 # kdelibs/win/ has to be built before the rest of kdelibs/
 # eventually it will be moved out from kdelibs/
 if (KDEWIN32_LIBRARY AND KDEWIN32_INCLUDE_DIR)
Index: modules/FindLibraryEx.cmake
===
--- modules/FindLibraryEx.cmake (revision 0)
+++ modules/FindLibraryEx.cmake (revision 0)
@@ -0,0 +1,111 @@
+#
+#  FIND_LIBRARY_EX - enhanced FIND_LIBRARY to allow the search for an
+#optional debug library with a WIN32_DEBUG_POSTFIX similar
+#to CMAKE_DEBUG_POSTFIX when creating a shared lib
+#it has to be the second and third argument
+#
+# Copyright (c) 2007, Christian Ehrlicher, [EMAIL PROTECTED]
+# Redistribution and use is allowed according to the terms of the BSD license.
+# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
+
+MACRO(FIND_LIBRARY_EX var_name win32_dbg_postfix_name dgb_postfix libname)
+
+  IF(NOT ${win32_dbg_postfix_name} STREQUAL WIN32_DEBUG_POSTFIX)
+
+# no WIN32_DEBUG_POSTFIX - simply pass all arguments to FIND_LIBRARY
+FIND_LIBRARY(${var_name}
+ ${win32_dbg_postfix_name}
+ ${dgb_postfix}
+ ${libname}
+ ${ARGN}
+)
+
+  ELSE(NOT ${win32_dbg_postfix_name} STREQUAL WIN32_DEBUG_POSTFIX)
+
+   IF(NOT WIN32)
+ # on non-win32 we don't need to take care about WIN32_DEBUG_POSTFIX
+
+ FIND_LIBRARY(var_name ${libname} ${ARGN})
+
+   ELSE(NOT WIN32)
+
+ # 1. get all possible libnames
+ SET(args ${ARGN})
+ SET(libnames_release )
+ SET(libnames_debug )
+
+ LIST(LENGTH args listCount)
+
+ IF(${libname} STREQUAL NAMES)
+   SET(append_rest 0)
+   LIST(APPEND args  )
+
+   FOREACH(i RANGE ${listCount})
+ LIST(GET args ${i} val)
+
+ IF(append_rest)
+   LIST(APPEND newargs ${val})
+ ELSE(append_rest)
+   IF(${val} STREQUAL PATHS)
+ LIST(APPEND newargs ${val})
+ SET(append_rest 1)
+   ELSE(${val} STREQUAL PATHS)
+ LIST(APPEND libnames_release ${val})
+ LIST(APPEND libnames_debug   ${val}${dgb_postfix})
+   ENDIF(${val} STREQUAL PATHS)
+ ENDIF(append_rest)
+
+   ENDFOREACH(i)
+
+ ELSE(${libname} STREQUAL NAMES)
+
+   # just one name
+   LIST(APPEND libnames_release ${libname})
+   LIST(APPEND libnames_debug   ${libname}${dgb_postfix})
+
+   SET(newargs ${args})
+
+ ENDIF(${libname} STREQUAL NAMES)
+ 
+ # search the release lib
+ FIND_LIBRARY(${var_name}_RELEASE
+  NAMES ${libnames_release}
+  ${newargs}
+ )
+
+ # search the debug lib
+ FIND_LIBRARY(${var_name}_DEBUG
+  NAMES ${libnames_debug}
+  ${newargs}
+ )
+
+ IF(${var_name}_RELEASE AND ${var_name}_DEBUG)
+
+   # both libs found
+   SET(${var_name} optimized ${${var_name}_RELEASE}
+   debug ${${var_name}_DEBUG})
+
+ ELSE(${var_name}_RELEASE AND ${var_name}_DEBUG)
+
+   IF(${var_name}_RELEASE)
+
+ # only release found
+ SET(${var_name} ${${var_name}_RELEASE})
+
+   ELSE(${var_name}_RELEASE)
+
+ # only debug (or nothing) found
+ SET(${var_name} ${${var_name}_DEBUG})
+
+   ENDIF(${var_name}_RELEASE)
+   
+ ENDIF(${var_name}_RELEASE AND ${var_name}_DEBUG)
+
+ MARK_AS_ADVANCED(${var_name}_RELEASE)
+ MARK_AS_ADVANCED(${var_name}_DEBUG)
+
+   ENDIF(NOT WIN32)
+
+  ENDIF(NOT ${win32_dbg_postfix_name} STREQUAL WIN32_DEBUG_POSTFIX)
+
+ENDMACRO(FIND_LIBRARY_EX)

Property changes on: modules\FindLibraryEx.cmake
___
Name: svn:eol-style
   + native

Index: modules/FindOpenSSL.cmake
===
--- modules/FindOpenSSL.cmake   (revision 715620)
+++ modules/FindOpenSSL.cmake   (working copy)
@@ -10,34 +10,13 @@
 # Redistribution and use is allowed according to the terms of the BSD license.
 # For details see the accompanying COPYING-CMAKE-SCRIPTS file.
 
+include(FindLibraryEx)
+
 # on win32 we additional need to link to libeay32.lib
 MACRO(OPENSSL_ADD_LIB_EAY_LIBS)
-   IF(MSVC)
-  # /MD and /MDd are the standard values - if somone wants to use
-  # others, the libnames have to change here too
-  # use also eay and libeay32 in debug as fallback for openssl  0.9.8b
-
-  FIND_LIBRARY(LIB_EAY_DEBUG NAMES libeay32MDd eay libeay libeay32)
-  FIND_LIBRARY(LIB_EAY_RELEASE NAMES libeay32MD eay libeay libeay32)
-
-  IF(MSVC_IDE)
- IF(LIB_EAY_DEBUG AND LIB_EAY_RELEASE)
-SET(OPENSSL_EAY_LIBRARIES optimized ${LIB_EAY_RELEASE} debug 
${LIB_EAY_DEBUG})
- ELSE(LIB_EAY_DEBUG

Can't build target with '+' in name (win32, msvc)

[Christian Ehrlicher]

Hi,

due to recent changes in kdepimlibs, I hit an error in cmake. It's 
impossible to create this target due to problems in the generated Makefile:


-8
# Object files for target gpgme++
gpgme++_OBJECTS = \
CMakeFiles\gpgme++.dir\gpgme++_automoc.obj \
CMakeFiles\gpgme++.dir\context.obj \
CMakeFiles\gpgme++.dir\key.obj \
CMakeFiles\gpgme++.dir\trustitem.obj \
CMakeFiles\gpgme++.dir\data.obj \
CMakeFiles\gpgme++.dir\callbacks.obj \
CMakeFiles\gpgme++.dir\eventloopinteractor.obj \
CMakeFiles\gpgme++.dir\keylistresult.obj \
CMakeFiles\gpgme++.dir\keygenerationresult.obj \
CMakeFiles\gpgme++.dir\importresult.obj \
CMakeFiles\gpgme++.dir\decryptionresult.obj \
CMakeFiles\gpgme++.dir\verificationresult.obj \
CMakeFiles\gpgme++.dir\signingresult.obj \
CMakeFiles\gpgme++.dir\encryptionresult.obj \
CMakeFiles\gpgme++.dir\engineinfo.obj
-8

nmake throws an error here.
gpgme++\CMakeFiles\gpgme++.dir/build.make(559) : fatal error U1001: 
syntax error : illegal character + in macro



It would be nice to solve it asap - the best solution would be to rename 
the lib back to gpgmepp until cmake is fixed.


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Unexpected behaviour of kde4automoc

[Christian Ehrlicher]

Matthias Kretz schrieb:
It must be the startDetached that is opening the new console. Please try the 
attached patch.



looks fine

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing

[Christian Ehrlicher]

Von: Andreas Pakulat [EMAIL PROTECTED]
 On 21.06.07 14:18:03, Thiago Macieira wrote:
  
  Matthias Kretz said:
   Hi,
  
   as I just got my second report that phonon doesn't link I thought I'd
   better
   implement a check that errors out if Qt has been compiled without
   visibility
   support but KDE is compiled with default hidden visibility.
  
   This is necessary for
   1. phonon which uses Q_DECL_EXPORT as export macro
   2. all plugins that export their entry symbols using Q_DECL_EXPORT or
 any
   other macro that uses Q_DECL_EXPORT
  
   Ok, to commit the attached patch?
  
  It's much easier and even probably better to define KDE_EXPORT as
  Q_DECL_EXPORT (similarly for KDE_IMPORT).
  
  The reason we don't do that is because qglobal.h cannot be included from
 C
  source files -- though IMHO it should.
 
 Unless I'm overlooking something that will break. I just recently fixed
 phonone which used
 
 if MAKE_PHONON_LIB
   define PHONON_EXPORT Q_DECL_EXPORT
 else
   define PHONON_EXPORT Q_DECL_IMPORT
 endif
 
 and while this works on Win32, it breaks on linux because Q_DECL_EXPORT
 doesn't evaluate to default-visibility (don't know the gcc command for
 that) but to nothing. At least on a default-built qt-copy. 
 
It's not the fault of Q_DECL_EXPORT but Q_DECL_IMPORT which is defined to 
nothing on linux.

Christian
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing

[Christian Ehrlicher]

Thiago Macieira schrieb:

Christian Ehrlicher said:

and while this works on Win32, it breaks on linux because Q_DECL_EXPORT
doesn't evaluate to default-visibility (don't know the gcc command for
that) but to nothing. At least on a default-built qt-copy.


It's not the fault of Q_DECL_EXPORT but Q_DECL_IMPORT which is defined to
nothing on linux.


That's not a problem on ELF/x86, but I do wonder how it compiles at all
under 64-bit.

Symbols marked hidden tell the compiler it can generate shorter calls,
instead of emitting a relocation to a full 64-bit jump. On x86-64, that
would be a 32-bit RIP-relative call; on Itanium, it would probably be a
one of the weird lengths, like 21- or 25-bit jump.

(Itanium can encode short immediates in a single 41-bit instruction, but a
full 64-bit displacement requires three instructions, 128 bits)

It's working because tt uses the export macro in a slightly different 
way then we do. Q_DECL_IMPORT is never used on linux.


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: make KDE4_AUTOMOC compatible to qmake

[Christian Ehrlicher]

Von: Matthias Kretz [EMAIL PROTECTED]
 Hi,
 
 I updated the patch so that it now adds a dependency on the moc generated
 file 
 and does not add the moc files in the add_library/add_executable calls.
 Works 
 fine with a clean build dir now, too.
 
Afair we had a similar discussion short after we switched to cmake. There is a 
difference in the moc file handling between qmake and cmake/automake. I don't 
remeber why this was introduced...


Christian
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [patch] fixes for compiling under mingw

[Christian Ehrlicher]

Alexander Neundorf schrieb:

On Wednesday 06 June 2007 10:32, Holger Schröder wrote:

Hi Alex, hi list,

i am trying to simplify compiling of kde on windows. for that i need to get
some changed into kdelibs/cmake/modules.

most of them add a cmake variable for the prefix where to find a library,
like gif, jpeg, etc.

and then there is a patch for findqt4.cmake.

the problem is, that the debug libs of qt 4 are nor found under windows,
because they are named QFood4 for the debug libraries.

so for every Qfoo4 in a find_library statement i added an Qfood4 entry.


Qt: ok
Since which Qt release is this so ?

Maybe try to reuse the existing msvc stuff to distinguish between debug 
and release libs.


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Source not regenerated after new kconfig_compiler executable

[Christian Ehrlicher]

Hi,

Don't know if it's intended or a bug in the dependency chain. The output 
from kconfig_compiler is not regenerated after I installed a new 
kconfig_compiler executable. Therefore I still got warnings about 
kstaticdeleter until I delete the sources by myself :)


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Source not regenerated after new kconfig_compiler executable

[Christian Ehrlicher]

David Faure schrieb:

On Tuesday 22 May 2007, Christian Ehrlicher wrote:

Hi,

Don't know if it's intended or a bug in the dependency chain. The output 
from kconfig_compiler is not regenerated after I installed a new 
kconfig_compiler executable. Therefore I still got warnings about 
kstaticdeleter until I delete the sources by myself :)


Yeah but would you really want to see all kconfig_compiler-generated files
re-created every time kdelibs is reinstalled - even though in 99% of the cases

from now on, the logic inside kconfig_compiler won't have changed?

(but it will have been relinked because kdecore changed).

Don't know - but it's maybe a more generic question. Should a generated 
file get regenerated when the generator is updated.

Maybe we need to install a cmake file with the version number of 
kconfig_compiler,
in order to trigger a recompilation only when the version of kconfig_compiler 
is newer than the version that was used to generate the current generated files...



I think a 'rm -fr build-dir' is easier :)

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

QtUiTools on win32 (again)

[Christian Ehrlicher]

Hi,

During the last posts about updating qt-copy to Qt4.3 I came back to the 
QtUiTools problem on win32.
We had no answer from the trolls if QtUiTools can't become a shared lib 
in Qt4.3. I just found a bugtracker entry: 
http://www.trolltech.com/developer/task-tracker/index_html?method=entryid=147626


I also asked on qt-interest, but no answer so far. :(

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Qt static libraries - pkgconfig again

[Christian Ehrlicher]

Holger Schröder schrieb:

On Friday 23 February 2007 21:38:56 Thiago Macieira wrote:

Simon Hausmann wrote:

Christian is right there, also because qmake does not generate
pkg-config files on Windows.

May I suggest then that we together standardise on a dependency file for
static libraries (and platforms where such a thing is necessary)? More or
less like the libtool .la file.

CMake will need it anyways for supporting static builds of other
applications.


well, pkg-config is available on win32, at least that is what 
http://pkgconfig.freedesktop.org/wiki/ says, although i haven´t tested it 
yet.


so what about this option: for qt 4.2 we leave things as they are, and for qt 
4.3 the trolls install .pc files on windows too, and we use them under linux 
and under windows ?


pkg-config is available on win32, but it's only used in msys environment 
(where you have a linux-like directory layout) - the location of the pc 
files is not defined on windows. A path can be added with 
PKG_CONFIG_PATH (afaik), but imho this just makes the whole kde 
compilation more complex than we gain advantages from using pkg-config 
on win32.


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Qt static libraries - pkgconfig again

[Christian Ehrlicher]

Thiago Macieira schrieb:
Qt has one static library that we use in KDE code: QtUiTools. Whichever 
reason the Trolls had to make it static is besides the point: it is 
static.


That means we must fetch its dependency info from the Qt installation into 
CMake. And Qt provides only one official way of doing that: via 
pkg-config.


So, I ask again: can we start supporting discovery of Qt via pkg-config by 
default on all systems? If that doesn't work, we'd have a fallback to the 
current discovery via qmake.



pkg-config on win32 is a bad idea... :(

Christian




signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: template definitions cannot nest(qdbusargument.h)

[Christian Ehrlicher]

Azman Minha schrieb:

Hi all,

I want to compile QtDBus and tools 


(http://www.kdelibs.com/wiki/index.php/Building_KDElibs_4_using_MS_Visual_Studio)

But I encounter this error.

qdbusargument.h(173) : error C2954: template definitions cannot nest.

My spec:
QT: 4.2.2
Compiler:Visual C++ 6.0

Any suggestion on what should I do?

msvc6 is not supported by kdelibs (and as it looks, qdbus is also not 
compilable with msvc6).

Use a recent compiler.

Christian Ehrlicher



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: template definitions cannot nest(qdbusargument.h)

[Christian Ehrlicher]

Thiago Macieira schrieb:

Christian Ehrlicher wrote:

qdbusargument.h(173) : error C2954: template definitions cannot nest.

My spec:
QT: 4.2.2
Compiler:Visual C++ 6.0

Any suggestion on what should I do?

msvc6 is not supported by kdelibs (and as it looks, qdbus is also not
compilable with msvc6).
Use a recent compiler.


KDELibs doesn't support MSVC++ 6.0, but Qt does. The code is a bug 
previously not known.


Because qdbus is not officially supported on win32 atm and I wonder that 
dbus/win32 is compilable with msvc6 ... :)


Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Merging of kdelibs_export.h and kdelibs_export_win.h

[Christian Ehrlicher]

David Faure schrieb:
 On Monday 22 January 2007 15:46, David Faure wrote:
 That makes a LOT of extra files to install in kdelibs. I am not sure we 
 gain a big advantage by doing that.
 I think modularity is always a huge advantage. 
 
 yesterday this change was made to kdelibs_export.h:
 -#define KSPELL2_EXPORT KDE_EXPORT
 +#define SONNET_EXPORT KDE_EXPORT
 
And this is still wrong!
-
kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
so it must be MAKE_SONNETCORE_LIB

once more recompiling whole kdelibs (but this time for win32 only) :(

Christian




signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Merging of kdelibs_export.h and kdelibs_export_win.h

[Christian Ehrlicher]

David Faure schrieb:
 On Tuesday 23 January 2007 19:16, Christian Ehrlicher wrote:
 Alexander Neundorf schrieb:
 On Tuesday 23 January 2007 18:36, David Faure wrote:
 On Monday 22 January 2007 15:46, David Faure wrote:
 That makes a LOT of extra files to install in kdelibs. I am not sure we
 gain a big advantage by doing that.
 I think modularity is always a huge advantage.
 yesterday this change was made to kdelibs_export.h:
 -#define KSPELL2_EXPORT KDE_EXPORT
 +#define SONNET_EXPORT KDE_EXPORT

 today I tried to compile one thing in kdebase, and *every single file in
 kdebase* had to be recompiled, even though *nothing* in kdebase uses
 kspell2/sonnet.
 ...
 /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender
 libkonq/CMakeFiles/konq.dir/konq_faviconmgr.o.

 I stand by what I said: we need to split it up ;)
 You have my full support.

 Can't this somehow autocreated by cmake for every subdir of kdelibs?
 Can't you collect them all in kde4_add_library()?
 
 I autocreate foo_export.h files with my kdesdk script, but I don't think we 
 can go
 to the next step of full automation; every subdir doesn't define its own lib.
 
That's clear - therefore I wanted to 'save' them inside
kde4_add_library() and create the header with another cmake macro. Don't
know if this is possible...
 Plus in some cases we might want an extra export macro that is only set when 
 unit
 tests are enabled (we do that in koffice, maybe one day we need that in 
 kdelibs too).
 
Then the new cmake command should look for kde_foo_export.h.cmake and
add the definitions instead creating an own header.

Just an idea :)


Christian

btw: just found out that we need some more sonnet_export macros... :(



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Merging of kdelibs_export.h and kdelibs_export_win.h

[Christian Ehrlicher]

Thiago Macieira schrieb:
 Christian Ehrlicher wrote:
 kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
 so it must be MAKE_SONNETCORE_LIB
 
 I am changing that symbol to sonnetcore_EXPORTS instead. I asked here and 
 no one opposed...
 
How you name the export is not the problem - you must just take care to
use the correct MAKE_foo_LIB in kdelibs_export_win.h. It does not affect
linux in any way.
I could not recompile kdelibs for some days, so I did not recognize that
sonnet exports were messed up on win32. Since sonnetcore and sonnetui
are created, we also have MAKE_SONNETCORE_LIB and MAKE_SONNETUI_LIB...
And there is one more problem inside sonnet - some sources for
sonnetcore are also used for sonnetui (looks like an old convienence lib
for me) which breaks compilation on win32 too.

I'll check all needed changes as soon as I've successfully build kdelibs.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Merging of kdelibs_export.h and kdelibs_export_win.h

[Christian Ehrlicher]

Jacob R Rideout schrieb:
  yesterday this change was made to kdelibs_export.h:
  -#define KSPELL2_EXPORT KDE_EXPORT
  +#define SONNET_EXPORT KDE_EXPORT
 
 And this is still wrong!
 -
 kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
 so it must be MAKE_SONNETCORE_LIB

 once more recompiling whole kdelibs (but this time for win32 only) :(

 
 Could someone explain the error to me, so that I don't mess up the build
 again.
 
I'll try. Don't we have a wiki page for this already? If not we should
create one.

On Windows you need to export your functions in a shared lib to allow
access to those functions from outside. At this point it's the same like
gcc's visibility support. The main difference is, that if you want to
use such an exported function, you need to decorate them in another way.
This means that you have to define FOO_EXPORT depending on what you want do:

#ifdef MAKE_SONNETCORE_LIB
// here we build the lib
# define SONNETCORE_EXPORT KDE_EXPORT
#else
// here we use the lib
# define SONNETCORE_EXPORT KDE_IMPORT
#endif

MAKE_FOO_LIB is automatically defined when you use kde4_add_library(foo
...).


Please ask if there is something unclear - I'm not very good in
explaining things in an understandable way :)

Christian




signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: shell wrappers for windows not using the proper paths

[Christian Ehrlicher]

Matt Rogers schrieb:
 Alexander Neundorf wrote:
 On Tuesday 05 December 2006 07:01, Christian Ehrlicher wrote:
 Matt Rogers schrieb:
 Hi,

 I've been trying to compile kdelibs with MSVS for about the past month
 or so now, and the one thing that's always tripped me up was being
 unable to compile the kdewidgets project. I had a look at the shell
 wrapper for makekdewidgets and noticed that it didn't include paths for
 the kdewin32 libraries or the win32 libraries necessary to run
 makekdewidgets. After I fixed this manually, I'm happy to report that I
 have a working build.

 Now to the questions. :)
 Do I need to have the missing paths that I added manually in my user's
 PATH variable already?

 Shouldn't the shell wrappers include these directories on Windows for us?

 Should I file a bug in our bugzilla about this?
 Imho you have to set the correct directories - at least we all do this:
 set
 PATH=E:\Qt\qt-4.2.2\bin;E:\Qt\qt-4.2.2\lib;%PATH%;D:\Programme\kdewin32\bin
 ;D:\Programme\win32libs\bin
 But the wrappers contain the paths to the kdelibs lib dir, right ?

 Bye
 Alex
 
 it does, but that doesn't matter if not all the libs are in the kdelibs 
 lib dir.
I don't see the problem here - it's the same like on linux...

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: shell wrappers for windows not using the proper paths

[Christian Ehrlicher]

Matt Rogers schrieb:
 Hi,
 
 I've been trying to compile kdelibs with MSVS for about the past month 
 or so now, and the one thing that's always tripped me up was being 
 unable to compile the kdewidgets project. I had a look at the shell 
 wrapper for makekdewidgets and noticed that it didn't include paths for 
 the kdewin32 libraries or the win32 libraries necessary to run 
 makekdewidgets. After I fixed this manually, I'm happy to report that I 
 have a working build.
 
 Now to the questions. :)
 Do I need to have the missing paths that I added manually in my user's 
 PATH variable already?
 
 Shouldn't the shell wrappers include these directories on Windows for us?
 
 Should I file a bug in our bugzilla about this?
 
Imho you have to set the correct directories - at least we all do this:
set
PATH=E:\Qt\qt-4.2.2\bin;E:\Qt\qt-4.2.2\lib;%PATH%;D:\Programme\kdewin32\bin;D:\Programme\win32libs\bin

But you're right - it's not mentioned on kdelibs.com

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: QtCore4.dll

[Christian Ehrlicher]

Stephan Kulow schrieb:
 Hi!
 
 I found out why kpat requires QtCore4 - it links both against Core and 
 Cored, everything in kdegames does: E.g.
 
 kdegames_LIB_DEPENDS:STATIC=C:/kde/qt-win-opensource-src-4.2.1/lib/QtCore4.lib;C:/kde/qt-win-opensource-src-4.2.1/lib/QtCored4.lib;kdecore;c:/kde/inst/lib/kdewin32d.lib;user32;shell32;ws2_32;C:/kde/qt-win-opensource-src-4.2.1/lib/QtXml4.lib;C:/kde/qt-win-opensource-src-4.2.1/lib/QtXmld4.lib;kdeui;kutils;kparts;kio;c:/kde/inst/lib/kde3support.lib;C:/kde/qt-win-opensource-src-4.2.1/lib/QtCore4.lib;C:/kde/qt-win-opensource-src-4.2.1/lib/QtCored4.lib;kdecore;c:/kde/inst/lib/kdewin32d.lib;user32;shell32;ws2_32;c:/kde/inst/lib/kdnssd.lib;C:/kde/qt-win-opensource-src-4.2.1/lib/QtXml4.lib;C:/kde/qt-win-opensource-src-4.2.1/lib/QtXmld4.lib;C:/kde/qt-win-opensource-src-4.2.1/lib/QtNetwork4.lib;C:/kde/qt-win-opensource-src-4.2.1/lib/QtNetworkd4.lib;
 
 As you can see it links all Qt libs twice. If I remove the QtCore4.lib 
 manually, kpat starts up fine, if not it crashes in random places, which 
 indicate that kpat uses different (binary incompatible) QMap code than 
 kdelibs does. But I have no idea where the code to create this, but I guess 
 in cmake itself.
 
There seems to be some problems in the generated KDELibsDependencies.cmake:

SET(kio_LIB_DEPENDS
E:/Qt/qt-4.2.1/lib/QtCore4.lib;E:/Qt/qt-4.2.1/lib/QtCored4.lib;...)
should be
SET(kio_LIB_DEPENDS
optimized;E:/Qt/qt-4.2.1/lib/QtCore4.lib;debug;E:/Qt/qt-4.2.1/lib/QtCored4.lib;...)

And the undocumented command foo_LINK_TYPE seems not to work like
expected. I stepped through cmTarget::AddLinkLibrary() and saw that
_LINK_TYPE is not recognized due to LinkLibraryType is always
cmTarget::GENERAL. But also removing the check for cmTarget::GENERAL
does not help... :(

btw: qtuitools.lib_LINK_TYPE is set to general instead optimized



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: QtCore4.dll

[Christian Ehrlicher]

Stephan Kulow schrieb:
 Am Donnerstag, 9. November 2006 11:12 schrieb Stephan Kulow:
 Am Donnerstag, 9. November 2006 10:50 schrieb Manuel Klimek:
 Hi,

 I'm just curious:
 was it already discussed to name the debug libraries *d.dll on windows?
 I don't want to start a 'religious' discussion ;-), but this would
 allow release and debug builds side by side on windows, where debug and
 release libraries mustn't be mixed.
 It was discussed in general and was discarded as under Unix at least those
 libraries are binary compatible. But I just tried to enable postfix for
 windows builds. Let's see how much breaks :)
 
 Meanwhile I found out that this breaks compilation, but I miss the time to 
 fix 
 it atm. So I guess we should briefly discuss if we want to keep it for 
 Windows or rather revert it? I'd prefer if it's fixed, but I can only do so 
 later.
 
I prefer the debug suffix too.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: I can't compile dbus!

[Christian Ehrlicher]

Von: defresco [EMAIL PROTECTED]
 Hi all,
 I'm Fabio from Italy, It's some day that I've been tried to compile
 kdelibs
 on win32 using Ms visual studio 2005 express. I've some problem to compile
 the Dbus. when i get the source from svn and succesfully patched, try
 Cmake
 -g nmake makefile ..\windbus\cmake but the error is: could not create
 named generator Namake Makefile 
You have to be case sensitive, see also 'cmake --help':

-G NMake Makefiles

Christian

btw: What has dbus to do with kde-buildsystem? 
-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: MSVC 2005

[Christian Ehrlicher]

Von: Stephan Kulow [EMAIL PROTECTED]
 Hi!
 
 I'm trying to collect some experience with building KDE using MSVC and I 
 fail so far, so I wonder if someone can help. I can build kdelibs using 
 NMake Makefiles just fine, but it doesn't want to work at all if I
 create 
 VS 2005 Project files.
 
 The main problem seems to me, that the .moc files generated are 
 automatically added to the project while compiling so later VC tries to 
 compile them on their own - which fails miserably for most of them (and if
 it succeeds it will get duplicated symbols).
 
 Is that a known problem?
 
Welcome in the windows hell :)

As I last tried with msvc vcproj, cmake was at 2.4beta and it worked (I only 
had troubles everytime a .vcproj was updated because msvc sometimes did not 
noticed it). I never tried it with 2.4.3. But I've a qt3 project with 
KDE3_AUTOMOC() and there all works fine...

Maybe I take a look on it this evening.

 Greetings, Stephan
 P.S. This is my first mail using Outlook Express, I hope it works out :)
 P.P.S. My main goal is to get a release of kpat for windows as a christmas
 present, so there is some time left to fix.
 

Christian
-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE/kdelibs/cmake/modules

[Christian Ehrlicher]

Christian Ehrlicher schrieb:
 SVN commit 597662 by chehrlic:
 
 This is not needed at all - it  worked before without and now it doesn' work 
 with msvc anymore!
 cmake adds those libs automagically afaik
 
I had to go back to rev. 597591 to get it kdelbis compile again with msvc!
Why did you remove all the dbus stuff and changed all the other things?
It compiled fine with mingw before.
Please fix those things / go back to rev 597591 and start over with your
mingw compile!

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE/kdelibs/cmake/modules

[Christian Ehrlicher]

Sebastian Sauer schrieb:
 On Saturday 21 October 2006 12:08, you wrote:
 Christian Ehrlicher schrieb:
 SVN commit 597662 by chehrlic:

 This is not needed at all - it  worked before without and now it doesn'
 work with msvc anymore! cmake adds those libs automagically afaik
 I had to go back to rev. 597591 to get it kdelbis compile again with msvc!
 Why did you remove all the dbus stuff and changed all the other things?
 It compiled fine with mingw before.
 Please fix those things / go back to rev 597591 and start over with your
 mingw compile!
 
 hmm... that's somewhat funny cause let's take a look at the commits I did (I 
 try to just outline what has changed);
 
 1. r597592
 
 -if (NOT QT_DBUSXML2CPP_EXECUTABLE)
 -   message(FATAL_ERROR Qt4 qdbusxml2cpp was not found. Make sure it has 
 been 
 built and installed by Qt)
 -endif (NOT QT_DBUSXML2CPP_EXECUTABLE)
 +if (NOT WIN32)
 +   if (NOT QT_DBUSXML2CPP_EXECUTABLE)
 +  message(FATAL_ERROR Qt4 qdbusxml2cpp was not found. Make sure it has 
 been built and installed by Qt)
 +   endif (NOT QT_DBUSXML2CPP_EXECUTABLE)
 +endif (NOT WIN32)
 
 This part is needed since the Qt 4.2.1 qmake does compile qdbusxml2cpp only 
 for unix-systems
 
When you would have asked at kde-windows, we would have told you that
you need windbus and that we're currently working on this topic.
 2. r597606
 
 -   # add the winsock2 library, using find_library or something like this 
 would probably be better
 -   set(KDEWIN32_LIBRARIES ${KDEWIN32_LIBRARY} user32 shell32 ws2_32)
 +   # add the winsock2 library
 +   find_library(WIN32_USER32_LIBRARY NAMES user32 PATHS 
 $ENV{WINDIR}/system32)
 +   find_library(WIN32_SHELL32_LIBRARY NAMES shell32 PATHS 
 $ENV{WINDIR}/system32)
 +   find_library(WIN32_WS2_LIBRARY NAMES ws2_32 PATHS $ENV{WINDIR}/system32)
 +   set(KDEWIN32_LIBRARIES ${KDEWIN32_LIBRARY} ${WIN32_USER32_LIBRARY} 
 ${WIN32_SHELL32_LIBRARY} ${WIN32_WS2_LIBRARY})
 
 You may note the set(KDEWIN32_LIBRARIES ${KDEWIN32_LIBRARY} user32 shell32 
 ws2_32) which was there before I touched the code and just got replaced. The 
 set() was totaly wrong anyway and I wonder it compiled at all since at least 
 it was missing additional -chars ( so, 
 set(KDEWIN32_LIBRARIES ${KDEWIN32_LIBRARY} user32 shell32 ws2_32) ) but 
 maybe cmake 2.4.3 did not throw an error before while 2.4.3 does cause 
 user32 is not an known keyword not was it a variable.
 
1.) you can't link agains shared libs on win32 (mingw can, but it's a
feature added by Ralf Habacker)
2.) user32, shell32 and ws2_32 is enough since cmake expands them to the
correct static import libs (libfoo.a/ foo.a for mingw amd foo.lib for
msvc) - they're  also available on your system 8see MinGW\lib)
 3. r597618
 
 # FindZLIB.cmake
 set(ZLIB_INCLUDE_DIR ${KDEWIN32_INCLUDES})
 find_library(ZLIB_LIBRARY NAMES zlib PATHS ${KDEWIN32_LIBRARY_PATH})
 ...
 
 if you look again at it, you may note that the relevant added code is in 
 a if(MINGW) block, so it should be independend of compiling on MS Visual 
 Studio except you use MINGW on MSVS? Then it should be propably checked for 
 that condition imho.
 
But it's superflous - why would you check for this twice? I don't think
this is needed for mingw only and it's checked for on other places (main
CMakeLists.txt)
 4. r597624
 
 - find_file(GNUWIN32_DIR_tmp gnuwin32 win32libs 
 + find_file(GNUWIN32_DIR_tmp gnuwin32 kdewin32 win32libs 
 
 This one was needed cause the kdewin32-package (where the relevant GnuWin32 
 files are located) is not named win32libs any longer (what was iirc the case 
 for Qt3, or?)
 
You should not mix gnuwin32 and kdewin32 ...
gnuwin32: a summary of all relavant external libs needed for kdelibs,
downloadable somewhere on Ralf Habackers sites, I also have an updated
version of this under the name 'win32libs' - both names are not that
optimal.
kdewin32: a small layer needed to emulate some posix function not
available on win32
 Anyway... where exactly does it break? The only thing that really changed for 
 all compilers was the 4. mention above. So, does revert it fix the break? 
 btw, without 1. and 2. it does _not_ compile on win32/mingw for me :-(
 
 btw, Laurent pointed me 
 to http://sourceforge.net/project/showfiles.php?group_id=171968; which 
 should help to get it finally compiled (biggest prob I saw so far was the 
 missing dbus-lib).
 
Imho it would be the best to revert all your changes and try again. If
you have problems, you should ask at kde-buildsystem or kde-windows for
help and then you maybe can check in the changes, if needed!

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: qdbus build error

[Christian Ehrlicher]

Von: David Faure [EMAIL PROTECTED]
 On Wednesday 23 August 2006 23:22, Mathew Yeates wrote:
  
  
   btw: qt-4.2.0-tp1 isn't the version from qt-copy and not supported
   anymore (you'll get kdeibs compile errors)
 
  huh? I'm just following the instructions at
 
 http://www.kdelibs.com/wiki/index.php/Building_KDElibs_4_using_MS_Visual_Studio
 
 Well we updated the requirement for qt last week.
 
  How do I check out qt-copy?
 
 For windows, you don't want to do that. qt-copy is unix only.
 But you want to find the windows version of the same snapshot as qt-copy
 uses.
 I'm not exactly sure which one that is though - Stephan did the update on
 monday;
 oh, from rsync, so I don't even have a snapshot version number to give
 you.
 But I assume there is a qt-windows snapshot from Monday 21 August?

Yes, qglobal.h says '#define QT_VERSION_STR   4.2.0-snapshot-20060821' :)

Christian

-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: qdbus build error

[Christian Ehrlicher]

Mathew Yeates schrieb:
 But I assume there is a qt-windows snapshot from Monday 21 August?

 
 Yes, qglobal.h says '#define QT_VERSION_STR   4.2.0-snapshot-20060821' :)

 Christian

   
 Thanks for you help.
 
 1) Where do I get this snapshot? The one I'm seeing at Trolltech is from 
 20060630.
 2) What do I do with this? Does it need to be patched?
 3) Which qdbus do I use? Is the one that comes with the snapshot okay to 
 use?
 
1. from ftp - is there another place to get this (without using rsync or
cvs?) ftp.trolltech.com/pub/qt/snapshots
Any newer snapshot may work also.

2. the msvc patch for 4.2.0-tp1 works with this snapshot too

3. you have to use windbus from sf.net (== dbus cvs +
windows-patch.diff). Before compiling qdbus you have to apply the patch
from windbus (qt-qdbus-win32.patch). Make sure the (currently hardcoded)
path to dbus.h is correct (tools/qdbus/src/src.pro)

HTH
Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: qtDbus broken?

[Christian Ehrlicher]

Mathew Yeates schrieb:
 This was working recently (within in the last week). But now with the 
 latest (30 minutes ago) 
 
 I am following the directions at 
 http://www.kdelibs.com/wiki/index.php/QtDBus
 
 When I try and build tools\qdbus the build fails because dbus.h cannot 
 be found. I traced qmake and it appears that my DBUSDIR is being ignored 
 so qmake never finds dbus.h
 
Afaik DBUSDIR was never an option with this patch, you have to set it
manually in qdbus/src/src.pro:

DBUS_INSTALL_DIR=d:/Programme/dbus

Is there a way to get an environment var within a pro-file?

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: qdbus build error

[Christian Ehrlicher]

Mathew Yeates schrieb:
 after modifying src.pro with
 INCLUDEPATH += $$(DBUSDIR)/include
 I now get compiler errors such as the following
It works fine here with hard coded path and snapshot from before two days.

btw: qt-4.2.0-tp1 isn't the version from qt-copy and not supported
anymore (you'll get kdeibs compile errors)

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: qdbus build error

[Christian Ehrlicher]

Mathew Yeates schrieb:
 btw: qt-4.2.0-tp1 isn't the version from qt-copy and not supported
 anymore (you'll get kdeibs compile errors)
   
 huh? I'm just following the instructions at
 http://www.kdelibs.com/wiki/index.php/Building_KDElibs_4_using_MS_Visual_Studio
 
 How do I check out qt-copy?
Use latest snapshot from trolltech ftp and apply the patches from
qt-copy. qt-copy was updated a few days ago and therefore the
information on kdelibs.com is outdated.

btw: [EMAIL PROTECTED] is a better place to discuss this.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: problem building kdelibs trunk

[Christian Ehrlicher]

Mathew Yeates schrieb:
 This is with msvc2005
 When I compile I get an error in kjsembed. The link command being 
 executed is
 -
 link /nologo @
 /out:..\..\bin\kjsembed.dll /PDB:C:\buildkdelibs\bin\kjsembed.pdb /dll  
 /STACK:1000 /machine:I386 /INCREMENTAL:YES /debug 
 $(kjsembed_OBJECTS) $(kjsembed_EXTERNAL_OBJECTS) 
 -LIBPATH:c:\buildkdelibs\bin\. -LIBPATH:c:\buildkdelibs\bin 
 -LIBPATH:c:\qt-win-preview-opensource-src-4.2.0-tp1\lib 
 -LIBPATH:c:\PROGRA~1\kdewin32\lib -LIBPATH:c:\win32libs\lib QtCored4.lib 
 kdecore.lib kdewin32d.lib user32.lib shell32.lib ws2_32.lib QtSvgd4.lib 
 QtXmld4.lib kjs.lib kdecore.lib QtCored4.lib QtCored4.lib 
 Qt3Supportd4.lib Qt3Supportd4.lib QtGuid4.lib QtGuid4.lib QtDBusd4.lib 
 QtDBusd4.lib zlib.lib bzip2.lib kdewin32d.lib user32.lib shell32.lib 
 ws2_32.lib pcre.lib pcreposix.lib kernel32.lib user32.lib gdi32.lib 
 winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib 
 advapi32.lib  
 --
 
 Note that QtUiTools is not being linked. Because of this, the file 
 qwidget_binding.cpp has an unresolved symbol
 (QUiLoader). Am I doing something wrong? Any fixes?
 
T_QTUITOOLS_LIBRARY is added with target_link_libraries (see
CMakeLists.txt). Maybe cmake did not find qtuitools for you. Take a look
at CMakeCache.txt.
What Qt version do you use?

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Dashboard

[Christian Ehrlicher]

Paulo Jorge Guedes schrieb:
 -Original Message-
 From: Bill Hoffman [mailto:[EMAIL PROTECTED]
 Sent: sexta-feira, 4 de Agosto de 2006 15:49
 To: kde-buildsystem@kde.org
 Subject: Dashboard

 The dashboard is looking much better!   It is good to see
 Visual Studio working again.  Looks like there is a small issue with
 mingw:

 d:\downloads\qt-win-preview-opensource-src-4.2.0-
 tp1\lib/libQtUiTools.a(formbuilder.o):formbuilder.cpp:(.text+0x990):
 multiple definition of `QFormBuilder::QFormBuilder()'
 d:\downloads\qt-win-preview-opensource-src-4.2.0-
 tp1\lib/libQtDesigner4.a(d000144.o):: first defined here
 Creating library file: ../../bin/libkjsembed.dll.a
 collect2: ld returned 1 exit status
 
 It's a Qt problem that is supposed to be fixed in the latest snapshots.
 The problem is I can only compile qdbus with the first 4.2 TP.
 
Why? Did qmake change that much?

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Re: Newbie: Howto convert qmake project to cmake

[Christian Ehrlicher]

 Original-Nachricht 
Datum: Tue, 11 Jul 2006 08:10:13 -0400
Von: William A. Hoffman [EMAIL PROTECTED]
An: kde-buildsystem@kde.org
Betreff: Re: Newbie: Howto convert qmake project to cmake

 At 07:50 AM 7/11/2006, Aron Boström wrote:
 Hi experts!
 
 I have a problem I have tried to solve for allmost a week now without
 success. 
 
 In /trunk/KDE/kdepim/views/conversationview I have the code of my
 qmake-based SoC project. It's at the moment Qt4 only, but that is about to 
 change.
 So I need to make it build with cmake. However, I can't. 
 
 When linking my executable i get undefined reference to 'vtable for
 EverySingleClassName'.
 I have tried to copy and edit CMakeLists.txts from  many places in
 kdepim, kdelibs and kdebase, as well as tried the same with Qt's hello world
 tutorials. As long as I only have one sourcefile ( main.cpp) everything works
 just fine, but when I extends the solution to two source files (set (my_SRC
 main.cpp widget.cpp)) I bang my head into the wall.
 
 It sounds like you are not running moc, that will cause undefined vtables
 in qt projects.

No, it's the old qmake vs. autotools way to include moc files.

qmake adds the moc-files to it's sources and compiles them separatly. 
autotools/ cmake needs them to be included in the sources with

#include mySource.moc


Also take care that they're named differently

qmake:
moc-header: moc_filename.cpp
moc-source: filename.moc

autotools:
moc-header: filename.moc
moc-source: don't know atm, maybe filename_moc.cpp ?


Christian
-- 


Echte DSL-Flatrate dauerhaft für 0,- Euro*!
Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: msvc: makekdewidgets

[Christian Ehrlicher]

Peter Kümmel schrieb:
 Something for the kdewin32 TODO list:
 
 
 makekdewidgets throws an assert in win/src/mmap.c:
 
 line 117:
   hfd = (HANDLE)_get_osfhandle( fd );
 
 
 When the mmap call is avoided then makekdewidgets
 does not crash:

I wonder how often I have to say this - you *can't* mix debug and relase
libs as you do here. Because of this I stopped msvc compilation - the
kdelibs need a debug prefix like the qt libs have.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: msvc: makekdewidgets

[Christian Ehrlicher]

Alexander Neundorf schrieb:
 On Sunday 14 May 2006 18:02, Christian Ehrlicher wrote:
 Peter Kümmel schrieb:
 Something for the kdewin32 TODO list:


 makekdewidgets throws an assert in win/src/mmap.c:

 line 117:
 hfd = (HANDLE)_get_osfhandle( fd );


 When the mmap call is avoided then makekdewidgets
 does not crash:
 I wonder how often I have to say this - you *can't* mix debug and relase
 libs as you do here. Because of this I stopped msvc compilation - the
 kdelibs need a debug prefix like the qt libs have.
 
 Ok, so what exactly is required ?
 
 if (MSVC)
set(DEBUG_POSTFIX _debug)
 endif (MSVC)
 
 and then always only use debug versions of all kde libs in debug build mode ?
 
Something in this way.
You also have to make sure to use kdewin32*d*.dll instead kdewin32.dll

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: msvc: qHash

[Christian Ehrlicher]

David Faure schrieb:
 On Thursday 11 May 2006 18:36, Peter Kümmel wrote:
 David Faure wrote:
 I'm confused. This file doesn't use QHash/QSet at all, so why is a QHash 
 implementation needed?
 Is it due to some other file hashing KSortableItems?

 Yes, compiling stops there because it couldn't find a qHash function with 
 the correct argument.
 
 Where's there? I am quite confused as to why any code would try to hash 
 KSortableItem or KSortableList.
 
 Do you mean that even kdecore/tests/ksortablelisttest doesn't compile?
 
http://marc.theaimsgroup.com/?l=kde-core-develm=113126965312032w=2

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

RE: FINDKDE4 win32

[Christian Ehrlicher]

 --- Ursprüngliche Nachricht ---
 Von: Paulo Jorge Guedes [EMAIL PROTECTED]
 An: kde-buildsystem@kde.org
 Betreff: RE: FINDKDE4 win32
 Datum: Fri, 05 May 2006 10:18:25 +0100
 
  -Original Message-
  From: David Faure [mailto:[EMAIL PROTECTED]
  Sent: quinta-feira, 4 de Maio de 2006 18:13
  To: kde-buildsystem@kde.org
  Subject: Re: FINDKDE4 win32
  
  On Thursday 04 May 2006 19:03, Paulo Jorge Guedes wrote:
   +   if (!WIN32)
   +  find_library(KDE4_KDESU_LIBRARY NAMES kdesu PATHS
   ${KDE4_LIB_INSTALL_DIR} NO_DEFAULT_PATH )
   +  set(KDE4_KDESU_LIBS ${kdesu_LIB_DEPENDS} ${KDE4_KDESU_LIBRARY}
 )
   +   endif (!WIN32)
  
  I would even say if(UNIX) since the notion of suing is very unix-like.
  Not that I have a non-windows non-unix case in mind right now to find
 out
  what's best ;)
  
  Anyway never use WIN32 for such things, since WIN64 exists too.
 
 There is if (WIN32) all over the code though :(
 
 What sould one use, (WIN32 || WIN64)?

Afair it was said that WIN32 should be better renamed to WINDOWS and that it
is also defined on WIN64.

Christian

-- 
GMX Produkte empfehlen und ganz einfach Geld verdienen!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: UI - files not processed with vcproj generator?

[Christian Ehrlicher]

Albert Astals Cid schrieb:
 A Diumenge 23 Abril 2006 17:24, Christian Ehrlicher va escriure:
 Hi,

 When trying to compile kdeui with mscv/vcproj ui_kspellui.h and the
 other ui_foo.h are not generated.
 
 Need to run qmake?
What should I do with qmake? It's a cmake-project ... :)

Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: UI - files not processed with vcproj generator?

[Christian Ehrlicher]

William A. Hoffman schrieb:
 At 11:46 AM 4/23/2006, Christian Ehrlicher wrote:
 Albert Astals Cid schrieb:
 A Diumenge 23 Abril 2006 17:24, Christian Ehrlicher va escriure:
 Hi,

 When trying to compile kdeui with mscv/vcproj ui_kspellui.h and the
 other ui_foo.h are not generated.
 Need to run qmake?
 What should I do with qmake? It's a cmake-project ... :)
 
 Please see my posts about PATH and the IDE.   Currently the vcproj
 builds do not work in kdelibs.  There are two reasons:
 
 1. perl must be in the PATH
 2. qt libraries need to be in the PATH.
 
 The visual studio IDE has its own environment.   It does not use
 the environment of the shell that launched it or the environment for
 the system.  So, the fix is to create .bat files that run all
 the tools during the build process of kdelibs.   To handle no rpath,
 kdelibs already uses a sh script to do something like this on unix.
 So, someone needs to create the .bat files that forward stuff.
 
I don't understand correct - I don't have problems with my environment
(I think) but I can't find a rule to create ui_kkeydialogui.h from
kkeydialogui.ui. For dcop2idlcpp rules are generated
(kmainwindowiface.kidl  knotificationmanager.kidl) but not fo moc and uic.

Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [MSVC8] libxml2 and libiconv

[Christian Ehrlicher]

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

KDE/kdelibs/win/include/msvc

[Christian Ehrlicher]

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: [MSVC8] libxml2 and libiconv

[Christian Ehrlicher]

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

RE: kdelibs build broken on OS X and Linux

[Christian Ehrlicher]

 --- Ursprüngliche Nachricht ---
 Von: Paulo Jorge Guedes [EMAIL PROTECTED]
 An: kde-buildsystem@kde.org
 Betreff: RE: kdelibs build broken on OS X and Linux
 Datum: Mon, 10 Apr 2006 12:20:07 +0100
 
  -Original Message-
  From: Ralf Habacker [mailto:[EMAIL PROTECTED]
  Sent: sábado, 8 de Abril de 2006 23:48
  To: kde-buildsystem@kde.org
  Subject: Re: kdelibs build broken on OS X and Linux
  
  Ralf Habacker schrieb:
 
 [...]
  BTW: I have tried to build kdelibs after a longer period from scratch,
  seems to work good on mingw. Nice work. :-)
 
 Could you compile kglobalaccel? 
 There is no win header for KGlobalAccelImpl yet...
 
Update your svn ...

Christian

-- 
Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: M_PI

[Christian Ehrlicher]

Paulo Jorge Guedes schrieb:
 I'm going out for the weekend and I won't have an internet connection.
 I also send the math.h file that fixes the compilation.
 
Sometimes you have really funny ideas - do you really think M$ change
their math.h to fit your needs?

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: kdeui/kglobalaccel_win.h

[Christian Ehrlicher]

Von: Thiago Macieira [EMAIL PROTECTED]
 Benjamin Reed wrote:
 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.
 
 kglobalaccel_win.h is in kdecore, for whatever reason. Probably forgotten 
 to be moved.
And kglobalaccel_emb.h too...
I'll move them to kdeui this evening.

Christian

-- 
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: MSYS Makefiles Generator

[Christian Ehrlicher]

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: QT_LSTAT

[Christian Ehrlicher]

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: MSYS Makefiles Generator

[Christian Ehrlicher]

William A. Hoffman schrieb:
 At 01:29 PM 4/3/2006, Paulo Jorge Guedes wrote:
   
 Hi, 

 It seems that CMakeDirectoryInformation.cmake files are not being
 correctly generated. Notice the path on the mkspecs entry:

 [...]
 D:/downloads/qt-win-opensource-src-4.1.1/include/Qt
 D:\downloads\qt-win-opensource-src-4.1.1\mkspecs/default
 D:/downloads/qt-win-opensource-src-4.1.1/include/QtCore
 [...]

 I cannot say for sure but it seems to happen always on the mkspecs
 entry.

 Can I make anything on my side to fix this?
 

 I noticed that on the dashboard.   Can you send me your CMakeCache.txt file?
 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 will work on the generation of the directory information file so that
 it will not have incorrect paths in it.)
   
I introduced QT_MKSPECS because I thought I need qplatformdefs.h. But I 
did it the way like all the other vars are generated...

Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Build errors

[Christian Ehrlicher]

Paulo Jorge Guedes schrieb:
 -Original Message-
 From: William A. Hoffman [mailto:[EMAIL PROTECTED]
 Sent: quarta-feira, 29 de Março de 2006 15:42
 To: kde-buildsystem@kde.org
 Subject: Re: Build errors

 What is the current status of the windows build?
 Is it time to set up a dashboard?   I have not done so
 yet, because it did not compile without errors.  Should
 kdelibs compile without errors on windows now?
 
 I can't test lately as I can't build Qt (from Trolltech) from source:
 
 $ make
 cd src  make -f Makefile 
 make[1]: Entering directory 
 `/d/kde/qt-win-opensource-src-4.1.3-snapshot-20060322/src'
 make[1]: *** No rule to make target `..\.qmake.cache', needed by `Makefile'.  
 Stop.
 make[1]: Leaving directory 
 `/d/kde/qt-win-opensource-src-4.1.3-snapshot-20060322/src'
 make: *** [sub-src-make_default-ordered] Error 2
 
Please inform you about how to compile programs with mingw:
./configure
mingw32-make
...

Also you must remove all msys/cygwin paths from your PATH environment
variable.
See qt-interest for qt-compiling problems.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Build errors

[Christian Ehrlicher]

Maarten Th. Mulders schrieb:
 Well, rebuild Qt 4.1.1 with the patches you mentioned. Building dcop.exe
 now fails with:
 
 Linking CXX executable ..\..\bin\dcop.exe
 dcop.obj : error LNK2019: unresolved external symbol
 __declspec(dllimport) public: bool __thiscall QUrl::hasQuery(void)const
  ([EMAIL PROTECTED]@@QBE_NXZ)
 referenced in function public: class QString __thiscall
 KUrl::encodedPathAndQuery(int,bool)const 
 ([EMAIL PROTECTED]@@QBE?AVQString@@[EMAIL PROTECTED])
 ..\..\bin\dcop.exe : fatal error LNK1120: 1 unresolved externals
 
 What did I do wrong?
 
You did not rebuild qt.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: kdewin32 build error

[Christian Ehrlicher]

Paulo Jorge Guedes schrieb:
 -Original Message-
 From: Ralf Habacker [mailto:[EMAIL PROTECTED]
 Sent: quarta-feira, 22 de Março de 2006 18:33
 To: kde-buildsystem@kde.org
 Subject: Re: kdewin32 build error

 Ralf Habacker schrieb:
 I'm using qt 4.1.0 and had the same problem. This is because recent
 kdeui sources (kactionclasses.h) requires a class QActionWidgetFactory
 (patch is here
 http://websvn.kde.org/trunk/qt-copy/patches/0119-qaction-
 widgetfactory.diff?rev=518837view=log)
 , which is only available kde svn qt source copy.

 Compiling kdelibs on windows requires currently that you take the latest
 qt sources from trolltech
 (http://www.trolltech.com/download/qt/windows.html), apply the patches
 located in http://websvn.kde.org/trunk/qt-copy/patches/ and recompile
 qt.
 Another way is to wait for the next public qt windows binary
 release,which has hopefully the required patches.  :-(


 Update:
 In
 http://websvn.kde.org/trunk/qt-copy/patches/README?rev=517298view=auto
 I found the following statement:

 This directory contains patches for Qt that haven't been accepted by
 TrollTech
 yet. All patches in this directory itself shouldn't make qt-copy
 incompatible
 to official Qt, patches adding new API etc. belong to the notsafe/
 subdirectory.

 Seems that this wasn't followed :-(
 
 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.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: seg fault genembed w/ keramaik

[Christian Ehrlicher]

Von: Kurt V. Hindenburg [EMAIL PROTECTED]
 Hello,
   getting farther along... any ideas where to start?
 
 make[2]: Entering directory 
 `/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake'
 Generating keramikrc.h
 cd /mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake/kstyles/keramik
  ../../bin/genembed 
 --file

/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake/kstyles/keramik/keramikPics.txt

 

/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake/kstyles/keramik/pixmaps.keramik
 /bin/sh: line 1:  7886 Segmentation fault  ../../bin/genembed 
 --file

/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake/kstyles/keramik/keramikPics.txt


/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake/kstyles/keramik/pixmaps.keramik
 make[2]: *** [kstyles/keramik/keramikrc.h] Error 139
 make[2]: Leaving directory 
 `/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake'
 make[1]: *** [kstyles/keramik/CMakeFiles/keramik.dir/all] Error 2
 make[1]: Leaving directory 
 `/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake'
 make: *** [all] Error 2
I don't know which snapshot you use, but when you don't have rev.518975 from
genembed.cpp this is because the png's are now 8 or 32bpp and genembed could
only handle 32bpp correct.
If you have rev.518975 then there is no other way than to debug this (it
worked fine for me on win32 some days ago)

Christian

-- 
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

RE: Build problems with cmake / msvc2005

[Christian Ehrlicher]

 Von: Michael Drüing [EMAIL PROTECTED]
snip 
 Okay, but then it should not only search in C:\Program Files\kdewin32 but
 also in $KDEDIR/lib, because I don't want my kde installed in c:\program
 files\kdewin32. I have set KDEDIR=d:\kde4 but CMake seems to ignore this.
 Or
 is there any other environment variable which I could set so that CMake
 finds my kde4 installation path?
 
 After copying the libraries to c:\program files\kdewin32, I get similar
 problems with the other libraries, like libz.lib. They seem to be expected
 in c:\program files\gnuwin32 or something. I have them in
 d:\devel\local\{lib,include}, which are in the default MSVC search paths
 defined by $LIB and $INCLUDE. These directories should also be searched
 for
 required libraries. Or maybe I'm missing something and there's already
 some
 env.variable which I can set to tell CMake where additional libraries can
 be
 found?
 
kdewin32.lib is independend from kde and should handled like any oher
external lib.
Maybe you're looking for CMAKE_LIBRARY_PATH / CMAKE_INCLUDE_PATH?
And when you've set GNUWIN32_DIR in cmakesetup to your location, it also
should find all other external libs too.

Christian

-- 
Feel free mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Build problems with cmake / msvc2005

[Christian Ehrlicher]

Michael Biebl schrieb:
 Why do these problems raise up once more?
 What's the problem to build  install kdewin32 *before* starting with
 kdelibs4?
 
 
  My problem was not to type make  make install  for kdewin32. I usually
 read the installation instruction and they clearly said so.
 The problem I had was, that FindKDEWin32.cmake looks for the library
 kdewin32.lib while by default the debug version is built and installed. So
 either the documentation should be updated, that kdelibs/win should be built
 with Release or RelWithDebInfo or FindKDEWin32 should look for
 kdewin32.lib and kdewin32d.lib
I had to change this to avoid using debug kdewin32 with kdelibs which
could lead to crashes. So yes, the documentation should be updated.

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: what version of qt to use?

[Christian Ehrlicher]

William A. Hoffman schrieb:
 For the dashboards at kitware, I did this:
 download qt-x11-opensource-src-4.1.0/
 
 Then, I applied some patch to:
 qsyntaxhighlighter.cpp 
 
 But, now the dashboards have errors, and I was told to use qt-copy.
 Is there another small patch?  What about windows?  I don't think
 qt-copy will build on windows.
 
The patches from qt-copy apply fine on qt/windows

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE_DEPRECATED

[Christian Ehrlicher]

Peter Kümmel schrieb:
 kdemacros:
 
 #ifndef KDE_DEPRECATED
 # ifndef Q_CC_MSVC
 #  define KDE_DEPRECATED Q_DECL_DEPRECATED
 # else
 #  define KDE_DEPRECATED
 # endif
 #endif
 
 Why is KDE_DEPRECATED disabled for msvc?
 Does it still not work, even not placed in front
 of the functions?
It is working, but KDE_DEPRECATED is placed behind the functions in most
of the cases and I won't change this in every kdelibs-header...

Christian



signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kde3support on win32 cannot link

[Christian Ehrlicher]

 Hello,
 
 I am compiling kde3support on win32 in MSVC 8 2005. When linking
 skde3support 
 linker shows the following errors:
snip 
 What is wrong? What must I do to correct the error?
Imho it works fine for me (don't know excatly since I don't recompile this
lib very often).
- do you use Qt4.1.1?
- is your svn up to date?
- did you try to recompile the two files the error come from?
- did you try to resolve the problem (since you want to compile kdelibs4 I
assume that you want to help us with kde4)

It looks like your builddir == srcdir:
C:\kdelibs4\kdelibs\bin\Release\kde3support.dll

This isn't a good idea (and I don't know excatly if cmake supports this).

Christian

btw: what has this problem todo with the buildsystem?

-- 
Feel free mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kde3support on win32 cannot link

[Christian Ehrlicher]

 Von: Rikardo Tinauer [EMAIL PROTECTED]
 Hello,
 
 * I am using the commercial version of Qt for win32, version 4.1.1.
 * I believe my svn is up to date, I downloaded files 2 days ago.
 * Yes I tried to recompile the files
 
 I tried reslovnig the problem. I found out that my Qt is built so it
 doesn't 
 include the symbols for the operator and copy constructor. Even if I tried
 compiling Qt that way it would not change anything, since there is no 
 implementation for these two methods, so symbols wouldn't be exported 
 anyways.
 
 But the main problem is that I don't know why the kde3support classes seek
 these symbols, I couldn't find any reference in the code for these
 symbols?
 
 I certantly want to help, since I believe you guys do the good job, making
 such an excellent desktop. I'we been using KDE for many years now. I also 
 believe enabling the kde4libs on win32 can gain momentum to opensource and
 linux development.
Thx for the informations. I'll try to recompile kde3support in the next few
days and take a look what's going wrong there.

Christian

btw: You'll need some patches for your Qt to compile kdelibs4 - see
http://websvn.kde.org/trunk/qt-copy/patches/ - at least 0112 is needed
afaik.

-- 
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Fwd: KDE/kdebase/libkonq

[Christian Ehrlicher]

 Von: Thiago Macieira [EMAIL PROTECTED]
 Benjamin Reed wrote:
 On 3/2/06, Thiago Macieira [EMAIL PROTECTED] wrote:
  On ELF systems using dynamic libraries, where such nonsense is not
  necessary, don't install the dependency libraries.
 
  To our Windows developers: how does MSVC solve such nonsense? Can it
  link to a DLL without requiring that DLL's dependencies to be listed?
  Or does it require you to know what dependencies a DLL has?
 
 On OSX you have to list all depends, as long as you're using symbols
 from the dependent library (even indirectly).
 
 Which is braindead.
 
 Sorry, but it is.
 
 If I upgrade a library I use in my simple program and it adds a new 
 dependency, I have to review my program's ld flags.
 
 For such brain-damaged systems, the installation of an .la file is a 
 requirement.
I don't think this is needed on win32 - otherwise we would had to link
kdelibs against win32 system libs what we're not doing.

Christian

-- 
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem