Re: make KDE4_AUTOMOC compatible to qmake
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.
Please CC me as I'm not subscribed to this list.
--
Matthias Kretz (Germany)<><
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: KDE4Macros.cmake
===
--- KDE4Macros.cmake (revision 671744)
+++ KDE4Macros.cmake (working copy)
@@ -173,11 +173,18 @@
file(READ ${_abs_FILE} _contents)
get_filename_component(_abs_PATH ${_abs_FILE} PATH)
- string(REGEX MATCHALL "#include +[^ ]+\\.moc[\">]" _match "${_contents}")
+ string(REGEX MATCHALL "#include +([\"<]moc_[^ ]+\\.cpp|[^ ]+\\.moc)[\">]" _match "${_contents}")
if (_match)
foreach (_current_MOC_INC ${_match})
string(REGEX MATCH "[^ <\"]+\\.moc" _current_MOC "${_current_MOC_INC}")
- get_filename_component(_basename ${_current_MOC} NAME_WE)
+ if(_current_MOC)
+ get_filename_component(_basename ${_current_MOC} NAME_WE)
+ else(_current_MOC)
+ string(REGEX MATCH "moc_[^ <\"]+\\.cpp" _current_MOC "${_current_MOC_INC}")
+ get_filename_component(_basename ${_current_MOC} NAME_WE)
+ string(REPLACE "moc_" "" _basename "${_basename}")
+ endif(_current_MOC)
+
set(_header ${_abs_PATH}/${_basename}.h)
set(_moc${CMAKE_CURRENT_BINARY_DIR}/${_current_MOC})
@@ -196,26 +203,12 @@
endforeach (_current_MOC_INC)
endif (_match)
- set_source_files_properties(${_abs_FILE} PROPERTIES AUTOMOC_FILES "${_moc_FILES_PROPERTY}")
+ set_source_files_properties(${_abs_FILE} PROPERTIES OBJECT_DEPENDS "${_moc_FILES_PROPERTY}")
endif (EXISTS ${_abs_FILE} AND NOT _skip)
endforeach (_current_FILE)
endmacro (KDE4_AUTOMOC)
-macro(KDE4_GET_AUTOMOC_FILES _list)
- set(${_list})
- foreach (_current_FILE ${ARGN})
- set(_automoc_FILES_PROPERTY)
- get_filename_component(_abs_FILE ${_current_FILE} ABSOLUTE)
- get_source_file_property(_automoc_FILES_PROPERTY ${_abs_FILE} AUTOMOC_FILES)
- if (_automoc_FILES_PROPERTY)
- foreach (_current_MOC_FILE ${_automoc_FILES_PROPERTY})
-list(APPEND ${_list} ${_current_MOC_FILE})
- endforeach (_current_MOC_FILE)
- endif (_automoc_FILES_PROPERTY)
- endforeach (_current_FILE)
-endmacro(KDE4_GET_AUTOMOC_FILES)
-
macro(KDE4_CREATE_PO_FILES)
set(_list_gmo)
file(GLOB _po_files *.po)
@@ -631,13 +624,11 @@
set(_first_SRC ${_with_PREFIX})
endif (${_with_PREFIX} STREQUAL "WITH_PREFIX")
- kde4_get_automoc_files(_automoc_FILES ${_first_SRC} ${ARGN})
-
if (KDE4_ENABLE_FINAL)
kde4_create_final_files(${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_final_cpp.cpp _separate_files ${_first_SRC} ${ARGN})
- add_library(${_target_NAME} MODULE ${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_final_cpp.cpp ${_separate_files} ${_automoc_FILES})
+ add_library(${_target_NAME} MODULE ${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_final_cpp.cpp ${_separate_files})
else (KDE4_ENABLE_FINAL)
- add_library(${_target_NAME} MODULE ${_first_SRC} ${ARGN} ${_automoc_FILES})
+ add_library(${_target_NAME} MODULE ${_first_SRC} ${ARGN})
endif (KDE4_ENABLE_FINAL)
if (_first_SRC)
@@ -717,14 +708,13 @@
# KDE4_ADD_EXECUTABLE(${_target_NAME} ${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_dummy.cpp ${ARGN} )
# else (WIN32)
# under UNIX, create a shared library and a small executable, which links to this library
- kde4_get_automoc_files(_automoc_FILES ${_SRCS})
if (KDE4_ENABLE_FINAL)
kde4_create_final_files(${CMAKE_CURRENT_BINARY_DIR}/kdeinit_${_target_NAME}_final_cpp.cpp _separate_files ${_SRCS})
- add_library(kdeinit_${_target_NAME} SHARED ${CMAKE_CURRENT_BINARY_DIR}/kdeinit_${_target_NAME}_final_cpp.cpp ${_separate_files} ${_automoc_FILES})
+ add_library(kdeinit_${_target_NAME} SHARED ${CMAKE_CURRENT_BINARY_DIR}/kdeinit_${_target_NAME}_final_cpp.cpp ${_separate_files})
else (KDE4_ENABLE_FINAL)
- add_library(kdeinit_${_target_NAME} SHARED ${_SRCS} ${_automoc_FILES})
+ add_library(kdeinit_${_target_NAME} SHARED ${_SRCS})
endif (KDE4_ENABLE_FINAL)
kde4_handle_rpath_for_library(kdeinit_${_target_NAME})
@@ -758,10 +748,8 @@
set(_add_executable_param EXCLUDE_FROM_ALL)
endif (NOT KDE4_BUILD_TESTS)
- kde4_get_automoc_files(_automoc_FILES ${ARGN})
+ add_executable(${_target_NAME} ${_add_executable_param} ${ARGN})
- add_executable(${_target_NAME} ${_add_executable_param} ${ARGN} ${_automoc_FILES})
-
set_target_properties(${_target_NAME} PROPERTIES
Re: make KDE4_AUTOMOC compatible to qmake
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: make KDE4_AUTOMOC compatible to qmake
On Thursday 07 June 2007, Christian Ehrlicher wrote: > 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... I just successfully compiled libphonon using qmake by #including moc_.cpp instead of .moc. And since my KDE4Macros.cmake supports it, it also still compiles with cmake. -- Matthias Kretz (Germany)<>< http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgp2hQJEmsSdV.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Cannot "make install" in KDE4 because CMake sets the wrong install-dir
Moin kdelibs from 2 days ago, Qt 4.3-final, CMake 2.4.6. OpenSUSE 10.2, latest svn of kdeedu. As you can see here http://rafb.net/p/KsCM3V63.html I am using a clean build-dir and using -DCMAKE_INSTALL_PREFIX=/home/kde4/kde/ I have not the slightest idea why make install wants the files to go to /usr. Can anyone help here? Please CC me in replies. Carsten signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [patch] fixes for compiling under mingw
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 Qd4 for the debug libraries.
>>
>> so for every Q4 in a find_library statement i added an Qd4 entry.
>>
>
> Qt: ok
> Since which Qt release is this so ?
>
> For the other cmake modules: where do these variables come from ?
> STRIGI_INSTALL_PREFIX
> SHARED_MIMEINFO_INSTALL_PREFIX
> WIN32LIBS_INSTALL_PREFIX
> KDEWIN32_INSTALL_PREFIX
>
>
> If they have to be set manually this isn't a very good idea.
> How about setting CMAKE_PROGRAM/INCLUDE/LIBRARY_PATH ?
>
> Or reusing some variable which is set by FindKDEWin32Libs.cmake or something
> like this ?
>
May be this approach helps. I splitted KDEWIN32 and GNUWIN32 into a
KDEWIN and KDEWIN32 module.
The KDEWIN module looks in different locations for windows supplementary
installations in the order:
for mingw
environment variable KDEWIN_DIR
/kdewin-mingw
/kdewin
/kdewin32
/gnuwin32
for msvc
environment variable KDEWIN_DIR
/kdewin-msvc
/kdewin
/kdewin32
/gnuwin32
This module sets CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH for further
cmake modules in the configure process and for compiling.
The KDEWIN32 module then searches only for the kdewin32 library in the
predefined pathes
The GNUWIN32 module is now obsolate.
BTW: An extension of the KDEWIN module may be to be able to use more
than one path or additional directories like /win32libs
Ralf
# - Try to find the directory in which the kdewin32 library and other win32
related libraries lives
#
# Once done this will define
#
# KDEWIN32_FOUND - system has KDEWIN32
# KDEWIN32_INCLUDES - the KDEWIN32 include directories
# KDEWIN32_LIBRARIES - The libraries needed to use KDEWIN32
#
# Copyright (c) 2006, Alexander Neundorf, <[EMAIL PROTECTED]>
# Copyright (c) 2007, Ralf Habacker, <[EMAIL PROTECTED]>
#
# Redistribution and use is allowed according to the terms of the BSD license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
if (WIN32)
if (NOT KDEWIN32_DIR)
if(NOT KDEWIN_FOUND)
find_package(KDEWIN REQUIRED)
endif(NOT KDEWIN_FOUND)
find_path(KDEWIN32_INCLUDE_DIR winposix_export.h
${CMAKE_INCLUDE_PATH}
${CMAKE_INSTALL_PREFIX}/include
)
# search for kdewin32 in the default install directory for applications
(default of (n)make install)
find_library(KDEWIN32_LIBRARY_DEBUG NAMES kdewin32d
PATHS
${CMAKE_LIBRARY_PATH}
${CMAKE_INSTALL_PREFIX}/lib
NO_SYSTEM_ENVIRONMENT_PATH
)
find_library(KDEWIN32_LIBRARY_RELEASE NAMES kdewin32
PATHS
${CMAKE_LIBRARY_PATH}
${CMAKE_INSTALL_PREFIX}/lib
NO_SYSTEM_ENVIRONMENT_PATH
)
# msvc makes a difference between debug and release
if(MSVC)
find_library(KDEWIN32_LIBRARY_DEBUG NAMES kdewin32d
PATHS
${CMAKE_LIBRARY_PATH
${CMAKE_INSTALL_PREFIX}/lib
NO_SYSTEM_ENVIRONMENT_PATH
)
if(MSVC_IDE)
# the ide needs the debug and release version
if( NOT KDEWIN32_LIBRARY_DEBUG OR NOT KDEWIN32_LIBRARY_RELEASE)
message(FATAL_ERROR "\nCould NOT find the debug AND release version
of the KDEWIN32 library.\nYou need to have both to use MSVC projects.\nPlease
build and install both kdelibs/win/ libraries first.\n")
endif( NOT KDEWIN32_LIBRARY_DEBUG OR NOT KDEWIN32_LIBRARY_RELEASE)
SET(KDEWIN32_LIBRARY optimized ${KDEWIN32_LIBRARY_RELEASE} debug
${KDEWIN32_LIBRARY_DEBUG})
else(MSVC_IDE)
string(TOLOWER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE_TOLOWER)
if(CMAKE_BUILD_TYPE_TOLOWER MATCHES debug)
set(KDEWIN32_LIBRARY ${KDEWIN32_LIBRARY_DEBUG})
else(CMAKE_BUILD_TYPE_TOLOWER MATCHES debug)
set(KDEWIN32_LIBRARY ${KDEWIN32_LIBRARY_RELEASE})
endif(CMAKE_BUILD_TYPE_TOLOWER MATCHES debug)
endif(MSVC_IDE)
else(MSVC)
if(KDEWIN32_LIBRARY_RELEASE)
set(KDEWIN32_LIBRARY ${KDEWIN32_LIBRARY_RELEASE})
else(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)
set(KDEWIN32_FOUND TRUE)
# add needed system libs
set(KDEWIN32_LIBRARIES ${KDEWIN32_LIBRARY} user32 shell32 ws2_
Re: kde4_add_test is not sufficient
On Wednesday 06 June 2007, Andreas Pakulat wrote: > On 05.06.07 19:33:55, Thiago Macieira wrote: > > Andreas Pakulat wrote: > > >Hi, > > > > > >I'd like to know wether its expected that one needs both kde4_add_test > > >and add_test to make tests work even if KDE4_BUILD_TESTS was set to off? > > > > > >If one doesn't tell cmake via add_test() that a testcase exists the make > > >test target doesn't find any tests, even after building them via make > > >. I think add_test should be included in kde4_add_test, or is > > >there a reason why this is not done? > > > > Because I forgot about it when I wrote the macro, most likely. > > So that means add_test can just be added to kde4_add_test? No, I don't think so. Not all test programs are unit tests that can run automatically. All those interactive GUI test programs need to be built with kde4_add_test (so that you can use "make krulertest"), but shouldn't be run automatically by 'make test', so we don't want to call add_test for them. The naming is a bit unfortunate IMHO. "kde4_add_test" is called this way to look like "kde4_add_executable", i.e. "build this test program" (which could be automated or interactive). But CMake's "add_test" means "run this automated test", and the two macros look too much alike which leads to confusion. Maybe kde4_add_test should be renamed to kde4_add_test_executable at least (like kde4_add_kdeinit_executable). To solve your problem, we could have kde4_add_unit_test I suppose, which would do both (kde4_add_test_executable + add_test). -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: kde4_add_test is not sufficient
On 07.06.07 09:00:21, David Faure wrote: > On Wednesday 06 June 2007, Andreas Pakulat wrote: > > On 05.06.07 19:33:55, Thiago Macieira wrote: > > > Andreas Pakulat wrote: > > > >Hi, > > > > > > > >I'd like to know wether its expected that one needs both kde4_add_test > > > >and add_test to make tests work even if KDE4_BUILD_TESTS was set to off? > > > > > > > >If one doesn't tell cmake via add_test() that a testcase exists the make > > > >test target doesn't find any tests, even after building them via make > > > >. I think add_test should be included in kde4_add_test, or is > > > >there a reason why this is not done? > > > > > > Because I forgot about it when I wrote the macro, most likely. > > > > So that means add_test can just be added to kde4_add_test? > > No, I don't think so. Not all test programs are unit tests that can run > automatically. > > All those interactive GUI test programs need to be built with kde4_add_test > (so that you can use "make krulertest"), but shouldn't be run automatically > by 'make test', so we don't want to call add_test for them. > > The naming is a bit unfortunate IMHO. "kde4_add_test" is called this way > to look like "kde4_add_executable", i.e. "build this test program" > (which could be automated or interactive). But CMake's "add_test" means > "run this automated test", and the two macros look too much alike which > leads to confusion. Ok, makes sense. > Maybe kde4_add_test should be renamed to kde4_add_test_executable > at least (like kde4_add_kdeinit_executable). Fine with me. > To solve your problem, we could have kde4_add_unit_test I suppose, > which would do both (kde4_add_test_executable + add_test). That would be good I think. So If nobody objects I'll do the renaming (and porting of trunk/KDE/) and the addition of the new macro next monday. Andreas -- Do not sleep in a eucalyptus tree tonight. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make KDE4_AUTOMOC compatible to qmake
On Wednesday 06 June 2007 12:57, Matthias Kretz wrote: > Hi, > > today I learned that qmake apparently can work with #included moc files but > only if they are of the form moc_.cpp. But KDE4_AUTOMOC wants them as > .moc. > > In order to make it easier to switch from qmake to cmake (and back) I > suggest the attached patch. > > There's one issue I don't understand yet: Why are the *.moc files (and with > my patch the moc_*.cpp files) added to add_library/add_executable? This is the official way to express the dependency of the target to the generated files. If the files added this way to a target don't have a known extension, they are not processed (compiled) but the dependency is created. This doesn't work for generated files which are included in a source file AND have a known extension (such as moc_foo.cpp). Using OBJECT_DEPENDS works more or less, but not 100%. So, please don't commit this and don't use this. While it will work in many cases, it will not always work and introduce problems. I think there is currently no way to tell cmake not to compile a file with a known extension. Even if this would be added for 2.4.7 or 2.4.8 it wouldn't help us since we require 2.4.5. IOW we have to stay with a non-source-file extension. Bye Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Cannot "make install" in KDE4 because CMake sets the wrong install-dir
On Thursday 07 June 2007 07:24, Carsten Niehaus wrote: > Moin > > kdelibs from 2 days ago, Qt 4.3-final, CMake 2.4.6. OpenSUSE 10.2, latest > svn of kdeedu. > > As you can see here > > http://rafb.net/p/KsCM3V63.html > > I am using a clean build-dir and using > > -DCMAKE_INSTALL_PREFIX=/home/kde4/kde/ > > I have not the slightest idea why make install wants the files to go to > /usr. > > Can anyone help here? Please CC me in replies. Your the third person who considers this new behaviour (KDE apps follow to kdelibs install location) a bug. It reuses the install dirs from the installed kdelibs. I changed it now so the install dirs are only reused if the current CMAKE_INSTALL_PREFIX equals the install dir from kdelibs. Let me know if that works for you as expected. You have to update kdelibs/cmake/modules/FindKDE4Internal.cmake to get the new behaviour. Bye Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: kde4_add_test is not sufficient
Hi, On Thursday 07 June 2007 03:00, David Faure wrote: > On Wednesday 06 June 2007, Andreas Pakulat wrote: > > On 05.06.07 19:33:55, Thiago Macieira wrote: > > > Andreas Pakulat wrote: > > > >Hi, > > > > > > > >I'd like to know wether its expected that one needs both kde4_add_test > > > >and add_test to make tests work even if KDE4_BUILD_TESTS was set to > > > > off? > > > > > > > >If one doesn't tell cmake via add_test() that a testcase exists the > > > > make test target doesn't find any tests, even after building them via > > > > make . I think add_test should be included in > > > > kde4_add_test, or is there a reason why this is not done? > > > > > > Because I forgot about it when I wrote the macro, most likely. > > > > So that means add_test can just be added to kde4_add_test? > > No, I don't think so. Not all test programs are unit tests that can run > automatically. > > All those interactive GUI test programs need to be built with kde4_add_test > (so that you can use "make krulertest"), but shouldn't be run automatically > by 'make test', so we don't want to call add_test for them. > > The naming is a bit unfortunate IMHO. "kde4_add_test" is called this way > to look like "kde4_add_executable", i.e. "build this test program" > (which could be automated or interactive). But CMake's "add_test" means > "run this automated test", and the two macros look too much alike which > leads to confusion. > > Maybe kde4_add_test should be renamed to kde4_add_test_executable > at least (like kde4_add_kdeinit_executable). That's just what I thought too, kde4_add_test_executable(). Beside that, maybe we're not using cmake/ctest optimal by testing via "make test" but we should do "ctest " instead... > To solve your problem, we could have kde4_add_unit_test I suppose, > which would do both (kde4_add_test_executable + add_test). Not sure we need this. If it just adds add_test() to kde4_add_test_executable() it might more confuse than help. Bye Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
