Re: Weird cmake 'errors'
On Friday 21 November 2008 19:13:54 Brad King wrote: Marijn Kruisselbrink wrote: When I try to compile any module other than kdelibs on Mac OSX, I get lots and lots of CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: kdecore, and similar lines. Fortunately cmake still manages to generate correct Makefiles, but it still is annoying. Is this something that is wrong in our usage of cmake, or is cmake 2.6.2 (and cmake cvs trunk) just broken on Mac OSX? CMake is expected to work on OSX. Your usage is exposing a problem with CMake. We did not expect that line to get hit. Does the message have any context information? Where does it appear in the CMake output? Can you please try to strip this down to a minimal example? The message does not have any more information. It appears between the 'configuring done' and 'generating done' lines when running cmake. It affects every kde module (except kdelibs), and I don't know enough of cmake to have any idea what would cause this to be able to get it down to a smaller example, to me it just seems cmake is very broken... Marijn ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Weird cmake 'errors'
On Wed, Nov 19, 2008 at 5:27 PM, Marijn Kruisselbrink [EMAIL PROTECTED] wrote: When I try to compile any module other than kdelibs on Mac OSX, I get lots and lots of CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: kdecore, and similar lines. Fortunately cmake still manages to generate correct Makefiles, but it still is annoying. Is this something that is wrong in our usage of cmake, or I can confirm this issue with the 4.1.80 packages that were just released on the packaging list as well -- kdepimlibs errors out as well. I've made a minimal test-case (attached). It outputs: ---(snip!)--- ... -- Found Phonon: /sw/lib/X11/lib/libphonon.dylib -- Found Phonon Includes: /sw/lib/X11/include/KDE;/sw/lib/X11/include -- Found KDE 4.2 include dir: /sw/lib/kde4-x11/include -- Found KDE 4.2 library dir: /sw/lib/kde4-x11/lib -- Found the KDE4 kconfig_compiler preprocessor: /sw/lib/kde4-x11/bin/kconfig_compiler -- Found automoc4: /sw/lib/X11/bin/automoc4 -- Configuring done CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: kdecore CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: kdeui CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: kio CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: solid -- Generating done -- Build files have been written to: /tmp/test/build Sin:/tmp/test/build ranger$ ---(snip!)--- This particular test case lets me do make afterwards and it still works. kdepimlibs, though, will just re-run cmake if I type make after the initial cmake command. -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/ getlibrarynamesinternal.tar.bz2 Description: BZip2 compressed data ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
no win32 application icon possible with kde4_add_kdeinit_executable
Hi,
for kwrite (kdebase/apps/kwrite) I tried to add an application icon
using the following cmake commands
kde4_add_app_icon(${kwrite_KDEINIT_SRCS} pics/hi*-app-kwrite.png)
kde4_add_kdeinit_executable(kwrite ${kwrite_KDEINIT_SRCS})
target_link_libraries(kdeinit_kwrite ${KDE4_KTEXTEDITOR_LIBS}
${KDE4_KIO_LIBS} ${KDE4_KPARTS_LIBS})
Unfortunally the icons is not created (usually there must be a line
like those: [ 0%] Generating kwrite.ico, kwrite.rc)
[100%] Building CXX object
kwrite/CMakeFiles/kdeinit_kwrite.dir/kwrite_win32lib_dummy.obj
kwrite_win32lib_dummy.cpp
Linking CXX static library ..\bin\kdeinit4_kwrite.lib
[100%] Built target kdeinit_kwrite
Generating kwritemain.moc
[100%] Built target kwrite_automoc
[100%] Building CXX object kwrite/CMakeFiles/kwrite.dir/kwrite_automoc.obj
kwrite_automoc.cpp
[100%] Building CXX object kwrite/CMakeFiles/kwrite.dir/kwritemain.obj
kwritemain.cpp
[100%] Building CXX object kwrite/CMakeFiles/kwrite.dir/kwrite_dummy.obj
kwrite_dummy.cpp
Linking CXX executable ..\bin\kwrite.exe
LINK : ..\bin\kwrite.exe not found or not built by the last incremental
link; performing full link
Creating library ..\bin\kwrite.lib and object ..\bin\kwrite.exp
[100%] Built target kwrite
Install the project...
-- Install configuration: Debug
-- Installing: E:/daten/kde/emerge-msvc-root/bin/kwrite.exe
-- Installing: E:/daten/kde/emerge-msvc-root/lib/kdeinit4_kwrite.lib
-- Up-to-date:
E:/daten/kde/emerge-msvc-root/share/applications/kde4/kwrite.desktop
-- Up-to-date: E:/daten/kde/emerge-msvc-root/share/apps/kwrite/kwriteui.rc
How can I add application icons on win32 to kdeinit executable beside to
shortcut the kdeinit stuff completly ?
Regards
Ralf
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: no win32 application icon possible with kde4_add_kdeinit_executable
On Tuesday 25 November 2008 19:29:13 Ralf Habacker wrote:
kde4_add_app_icon(${kwrite_KDEINIT_SRCS} pics/hi*-app-kwrite.png)
I think you meant here
kde4_add_app_icon(kwrite_KDEINIT_SRCS pics/hi*-app-kwrite.png)
In any case, this will most likely put the icon in the .dll for the kdeinit
module, instead of in the executable.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Software Engineer - Nokia, Qt Software
Qt Software is hiring - ask me
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
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: no win32 application icon possible with kde4_add_kdeinit_executable
Thiago Macieira schrieb:
On Tuesday 25 November 2008 19:29:13 Ralf Habacker wrote:
kde4_add_app_icon(${kwrite_KDEINIT_SRCS} pics/hi*-app-kwrite.png)
I think you meant here
kde4_add_app_icon(kwrite_KDEINIT_SRCS pics/hi*-app-kwrite.png)
sure, copy and paste error - this fixed my problem
In any case, this will most likely put the icon in the .dll for the kdeinit
module, instead of in the executable.
no, after fixing the above mentioned issue, thanks to alex work the icon
is added to the resulting exe - :-)
Thanks for your help
Regards
Ralf
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Weird cmake 'errors'
On Tuesday 25 November 2008, Benjamin Reed wrote:
On Wed, Nov 19, 2008 at 5:27 PM, Marijn Kruisselbrink
[EMAIL PROTECTED] wrote:
When I try to compile any module other than kdelibs on Mac OSX, I get
lots and lots of CMake Internal Error (please report a bug) in
CMakeLists.txt: GetLibraryNamesInternal called on imported target:
kdecore, and similar lines. Fortunately cmake still manages to generate
correct Makefiles, but it still is annoying. Is this something that is
wrong in our usage of cmake, or
I can confirm this issue with the 4.1.80 packages that were just
released on the packaging list as well -- kdepimlibs errors out as
well.
I've made a minimal test-case (attached).
Is this really minimal ?
I would suspect the following might already be enough ?
--
find_package(KDE4 REQUIRED)
set(failure_LIB_SRCS dummy.cpp)
kde4_add_library(failure SHARED ${failure_LIB_SRCS})
target_link_libraries(failure ${KDE4_KIO_LIBS})
--
Can you please try ?
I guess it's caused by target_link_libraries().
If there are no errors, add the set_target_properties() call again.
I think the install() should be innocent.
Can you get a backtrace from the point where the error message is printed ?
It is in Source/cmTarget.cxxm void cmTarget::GetLibraryNamesInternal()
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Weird cmake 'errors'
Alexander Neundorf wrote: On Tuesday 25 November 2008, Benjamin Reed wrote: On Wed, Nov 19, 2008 at 5:27 PM, Marijn Kruisselbrink [EMAIL PROTECTED] wrote: When I try to compile any module other than kdelibs on Mac OSX, I get lots and lots of CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: kdecore, and similar lines. Fortunately cmake still manages to generate correct Makefiles, but it still is annoying. Is this something that is wrong in our usage of cmake, or I can confirm this issue with the 4.1.80 packages that were just released on the packaging list as well -- kdepimlibs errors out as well. I've made a minimal test-case (attached). Is this really minimal ? Based on possible paths in source code, I've produced this minimal test case that does not depend on KDE: cmake_minimum_required(VERSION 2.6) project(FOO C) add_library(foo SHARED IMPORTED) add_executable(bar bar.c) target_link_libraries(bar foo) install(TARGETS bar DESTINATION bin) The problem is created only on Mac. It is when CMake constructs the install_name_tool call for target 'bar' to try to map the install_name embedded in 'bar' to look for 'foo'. The code that does this incorrectly assumes 'foo' is a non-imported target. I'm looking into a fix. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: wildcards in DEPENDS
On Thursday 20 November 2008, Matthias Kretz wrote: On Thursday 20 November 2008 10:27:11 Matthias Kretz wrote: Now, for some reason qt4_generate_moc stopped working for me. I don't see how that could be related, if it is and you have an idea please take a look. It seems I found the problem: the OBJECT_DEPENDS I added in Automoc4Config overwrites the OBJECT_DEPENDS from qt4_generate_moc. I changed automoc to also use macro_add_file_dependency now and kdelibs compiles again. New atuomoc patch attached. I'd like to commit this, please review. Ok, some comments. The macro macro_add_file_dependencies() is only available in kdelibs/ and projects using kdelibs/, i.e. it shouldn't be used in automoc. The macro is in kdelibs/cmake/modules/MacroAddFileDependencies.cmake, you can just copy it. But, why is this dependency required now ? Currently the source files don't depend on the automoc-generated file and it works ? About the add_custom_target(automoc4_init): this is done now unconditionally. I.e. if you do find_package(Automoc4) twice, it will be executed twice, cmake will then complain about the target being added twice. So you should test wether the target has already been added. With CMake = 2.6.2 you can do if(NOT TARGET automoc4_init) ... With version before that you can do get_target_property(AUTOMOC4_INIT_TYPE automoc4_init TYPE) if the target has already been created, you will get UTILITY as result (which is TRUE if tested in an if()), and AUTOMOC4_INIT_TYPE-NOTFOUND if it hasn't been created yet (which is false if tested with if()). Is it still necessary to have different versions for Windows and non-Windows ? Instead of putting all files into automoc4_init.files on every cmake run, could you do it similar to as you did it before ? I.e. instead if touching the file in the add_custom_command(), add that filename to automoc4_init.files, so in the next make, the automoc4_init target will just touch these files and not all ? This could be done by adding that to the automoc4 executable or by executing an additional command in the same add_custom_command (echo should work) Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Weird cmake 'errors'
Brad King wrote: The problem is created only on Mac. It is when CMake constructs the install_name_tool call for target 'bar' to try to map the install_name embedded in 'bar' to look for 'foo'. The code that does this incorrectly assumes 'foo' is a non-imported target. I'm looking into a fix. Okay, the solution is to just ignore imported targets to which 'bar' links. Their install_name will not change anyway. /cvsroot/CMake/CMake/Source/cmInstallTargetGenerator.cxx,v -- Source/cmInstallTargetGenerator.cxx new revision: 1.67; previous revision: 1.66 We'll include this in the 2.6 branch. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Weird cmake 'errors'
On Tuesday 25 November 2008, Brad King wrote: Brad King wrote: The problem is created only on Mac. It is when CMake constructs the install_name_tool call for target 'bar' to try to map the install_name embedded in 'bar' to look for 'foo'. The code that does this incorrectly assumes 'foo' is a non-imported target. I'm looking into a fix. Okay, the solution is to just ignore imported targets to which 'bar' links. Their install_name will not change anyway. You rock :-) So we will require 2.6.3 on OSX as soon as it is released. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
