|
Notes |
|
|
(0014078)
|
|
Alex Neundorf
|
|
2008-11-09 12:16
|
|
Please have a look at FindKDE4.cmake.
In cross compiling mode, kde4-config is still searched for, but it is not executed (because this doesn't work when cross compiling). Instead its location is used as a hint for the location of FindKDE4Internal.cmake. Also the different extension is taken into account.
Where and how does it fail for you ?
Alex |
|
|
|
(0014109)
|
|
Ben Boeckel (mathstuf)
|
|
2008-11-14 08:37
|
|
I get the following error:
$ cmake -DCMAKE_TOOLCHAIN_FILE=../src/cross-mingw32.cmake ../src/
CMake Error at /usr/share/cmake/Modules/FindKDE4.cmake:44 (MESSAGE):
ERROR: Could not find KDE4 kde4-config
Call Stack (most recent call first):
CMakeLists.txt:16 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
My toolchain file is:
CMAKE_MINIMUM_REQUIRED(VERSION 2.5.0)
SET(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER i386-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i386-mingw32-g++)
SET(CMAKE_FIND_ROOT_PATH /mnt/storage/kde4win/root)
SET(CMAKE_INSTALL_PREFIX /mnt/storage/kde4win/root)
SET(CMAKE_MODULE_PATH ${CMAKE_FIND_ROOT_PATH}/share/apps/cmake/modules)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
The paths in the toolchain file is where I extracted all of the KDE4Windows tarballs.
$ cd /mnt/storage/kde4win/root/
$ find -name kde4-config.exe
./bin/kde4-config.exe
Anything else that would be useful? |
|
|
|
(0014335)
|
|
Alex Neundorf
|
|
2008-12-13 18:19
|
|
Does it help if you (just for testing) rename the kde4-config.exe to kde4-config ? (it shouldn't).
It should actually be found. Strange.
Can you run strace to see what it looks for ?
Alex |
|
|
|
(0014417)
|
|
Ben Boeckel (mathstuf)
|
|
2008-12-22 17:19
|
|
After making a symlink from kde4-config -> kde4-config.exe:
% cmake -DCMAKE_TOOLCHAIN_FILE=../src/cross-mingw32.cmake ../src
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/local/bin/i386-mingw32-gcc
-- Check for working C compiler: /usr/local/bin/i386-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/local/bin/i386-mingw32-g++
-- Check for working CXX compiler: /usr/local/bin/i386-mingw32-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Automoc4: AUTOMOC4_EXECUTABLE-NOTFOUND
-- Found Perl: /usr/bin/perl
CMake Error at /mnt/storage/kde4win/root/share/apps/cmake/modules/FindKDE4Internal.cmake:373 (message):
Couldn't parse KDE version string from the kde4-config output:
sh: /mnt/storage/kde4win/root/bin/kde4-config: cannot execute binary file
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindKDE4.cmake:81 (FIND_PACKAGE)
CMakeLists.txt:16 (FIND_PACKAGE)
Does it think it's still in *nix-like when searching for some reason? Attaching strace output. The first one is when run against a clean build dir, second is when cmake is run again. |
|
|
|
(0014418)
|
|
Ben Boeckel (mathstuf)
|
|
2008-12-22 17:22
|
|
|
Umm...those are wrong...and I seem to have messed up a cleanup and gotten rid of my cross-compile files...will repost them once I get it cleared up :/ . |
|
|
|
(0014419)
|
|
Ben Boeckel (mathstuf)
|
|
2008-12-22 17:58
|
|
|
Alright, got it fixed. The first two files were mistakes. The first file (strace-output-before-link) is the output before the link is made. After the link is made, the other two files are subsequent runs on a blank built directory. |
|
|
|
(0014503)
|
|
Alex Neundorf
|
|
2009-01-09 18:20
|
|
Ok, this is indeed a real bug, not FindKDE4.cmake specific.
The problem is that find_program() calls SystemTools::FindProgramPath(), which uses SystemTools::GetExecutableExtension() to add the executable suffix to the filename, but this is done using an #ifdef, i.e. determined at cmake build time :-/
For crosscompiling we need to do something else.
Alex |
|
|
|
(0016569)
|
|
Alex Neundorf
|
|
2009-05-26 18:57
|
|
I'm not quite sure what the best behaviour is, whether find_program() should search for executables with the suffix of the host or the target platform.
In many cases this will not matter, since for many platforms the suffix is empty, so there is no difference then.
A significant case where it does matter is when cross compiling to or from Windows. Usually the other platform will not have the exe suffix as Windows does.
So what to do then ?
Usually, when you call find_program(), the goal is to run this executable later on.
E.g. for tools like perl, ruby, awk etc. you probably want a version from the host system, i.e. with the host suffix.
OTOH if it is an executable which provides information about the target platform, as e.g. kde4-config or qmake, finding the host version of the tool usually is not the right thing. But even if the target platform verson of the tool is found, you will (usually) not be able to run it. It still can be useful if it is e.g. a shell script, or if really only the location is needed, and it is not executed.
Should this maybe coupled with CMAKE_FIND_ROOT_PATH ?
I.e. when searching in the target system path, check for the executable with the suffix of the target platform, but when searching in the "normal" host directories, use the host suffix ?
This would probably be the right thing in many cases, but not in all, e.g. if some path in the target platform tree was already found using FIND_XXX() and is then used as HINT or PATH for FIND_PROGRAM(), then cmake doesn't "know" that this path is in the target tree.
An additional keyword for find_program() ?
Alex |
|
|
|
(0023798)
|
|
Alex Neundorf
|
|
2010-12-08 11:47
|
|
0011583 is related to this one.
Alex |
|
|
|
(0030576)
|
|
Alex Neundorf
|
|
2012-08-13 14:41
|
|
I don't think I'll have time to work on this for 2.8.10.
|
|
|
|
(0041468)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
strace-output (635) 2008-12-22 17:19