[cmake-developers] Building with Qt for the Raspberry Pi with CMake
Alexander Neundorf
neundorf at kde.org
Thu Apr 11 15:01:36 EDT 2013
On Thursday 11 April 2013, Stephen Kelly wrote:
> Hi,
>
> This is mostly just feedback on some experience with cross-compiling.
>
> As part of trying to figure out to what extent Qt 5 needs to be patched to
> solve the kind of issue raised in
>
> http://public.kitware.com/Bug/view.php?id=14041
>
> and fixed in 6c613b433c45efb0bb013a6bd668cbb8ac740259, I've been toying
> with building Qt 5 for the Raspberry Pi (raspbian image).
>
> I configured Qt like this:
>
> /home/stephen/dev/src/qtbase-stable/configure -prefix
> /home/stephen/dev/prefix/rpi -release -device linux-rasp-pi-g++ -make libs
> - device-option CROSS_COMPILE=/home/stephen/rpi/gcc-4.7-linaro-rpi-
> gnueabihf/bin/arm-linux-gnueabihf- -sysroot /home/stephen/rpi/rasp-pi-
> rootfs/ -opensource -confirm-license -no-pch
>
> [From the prefix you'll notice I'm not trying to reproduce #14041 here yet]
>
> I can use the resulting Qt 5 build by passing a prefix and toolchain:
>
> cmake .. -DCMAKE_PREFIX_PATH=/home/stephen/rpi/rasp-pi-
> rootfs/home/stephen/dev/prefix/rpi/ -
> DCMAKE_TOOLCHAIN_FILE=../rpiToolchain.cmake
>
> $ cat ../rpiToolchain.cmake
>
> set(CMAKE_SYSTEM_NAME Linux)
>
> set(CMAKE_C_COMPILER /home/stephen/rpi/gcc-4.7-linaro-rpi-
> gnueabihf/bin/arm-linux-gnueabihf-gcc)
>
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>
> [Side note, a colleague is working on a patch to generate such a toolchain
> file as part of the Qt build. The Qt mkspecs have all needed information.
> Any comments on that?]
I think that's a good idea.
Qt, once built, knows where the compiler is and what the target operating
system is, so it is a good source of information for that.
It also knows at least some part of CMAKE_FIND_ROOT_PATH, that would be its
own install locations, maybe it knows even more about where things are to be
found for the target ?
> I can then build GammaRay for the Pi if I patch it like this:
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index ca7a377..ea0b8d6 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -91,6 +91,32 @@ if(Qt5Core_FOUND)
> include("cmake/ECMQt4To5Porting.cmake")
> include_directories(${QT_INCLUDES}) # TODO: Port away from this.
>
> +
> + find_library(QTGUI_EGL_LIB EGL
> + PATHS /home/stephen/rpi/rasp-pi-rootfs/opt/vc/lib NO_DEFAULT_PATH)
/home/stephen/rpi/rasp-pi-rootfs/opt/vc/ should probably be part of
FIND_ROOT_PATH.
...
> It fails with the following output:
>
> Change Dir: /home/stephen/dev/src/kdab/gammaray/rpi/CMakeFiles/CMakeTmp
>
> Run Build Command:/home/stephen/rpi/rasp-pi-rootfs/usr/bin/make
> "cmTryCompileExec1792583416/fast"
>
> /home/stephen/rpi/rasp-pi-rootfs/usr/bin/make: 1:
> /home/stephen/rpi/rasp-pi-rootfs/usr/bin/make: Syntax error: word
> unexpected (expecting ")")
>
> CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
> CMakeLists.txt:17 (project)
>
>
> The problem is that it is finding make in the sysroot, but it does work if
> I additionally pass:
>
> -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER
>
> to cmake. Even though CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is set to NEVER in
> my toolchain file, I suppose that is processed to late already to take
> effect for the compiler sanity check.
>
> Maybe CMake should imply -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER for the
> make tool (and for other tools needed that early in the cmake run).
The toolchain file is processed very early, it should be read early enough so
that this works.
Ok, I just checked, Before anything else, CMakeUnixFindMake.cmake is executed,
I think initiated by project(). After that CMakeDetermineSystem.cmake is
executed, and then, after uname has been searched, the toolchain file has been
loaded. Adding MODE=NEVER to the cmake modules which search CMAKE_MAKE_PROGRAM
should help.
Somebody proposed a find_tool() which would be used for finding executables
needed for building, as opposed to find_program(), which just finds any
executable.
Alex
More information about the cmake-developers
mailing list