[cmake-developers] Building with Qt for the Raspberry Pi with CMake

Alexander Neundorf neundorf at kde.org
Wed Apr 17 15:34:34 EDT 2013


On Tuesday 16 April 2013, Stephen Kelly wrote:
> Brad King wrote:
> > On 04/16/2013 10:41 AM, Stephen Kelly wrote:
> >> That means that the include directories of an upstream package will have
> >> to prefix each path with "${CMAKE_FIND_ROOT_PATH}" in order to be useful
> >> in both cross compiling contexts and
> >> non-cross-compile-but-direct-on-target contexts.
> >> 
> >> We might be able to generate something for INTERFACE_INCLUDE_DIRECTORIES
> >> of exported targets. Pity we didn't have cases like this in mind when
> >> designing that feature.
> > 
> > Shouldn't all these paths be computed relative to the install prefix,
> > which is computed relative to the package config or targets file
> > location?
> > 
> > See an example here:
> >  http://www.cmake.org/Bug/view.php?id=14041
> > 
> > that does it for target locations.  The include paths should be the
> > same.  If an $<INSTALL_INTERFACE:...> value uses $<INSTALL_PREFIX>
> > should it not work already?
> 
> Right, I was over-simplifying. Actually I think there are two scenarios.
> 
> The one which uses find_path works:
> 
>  # Qt5::Gui is an imported target generated by the Qt build.
>  add_library(Qt5::Gui SHARED IMPORTED)
> 
>  # Find "/opt/vc/include". We know it contains GLES2/gl2.h because
>  # the Qt build already determined that. Using the find_path command
>  # though means that cmake will find it in the CMAKE_FIND_ROOT_PATH
>  find_path(Qt5Gui_OPENGL_INCLUDE_DIRS GLES2/gl2.h
>    PATHS "/opt/vc/include"
>    NO_DEFAULT_PATH)
> 
>  # Qt5Gui_OPENGL_INCLUDE_DIRS is now
> /home/stephen/rpi_rootfs/opt/vc/include # if cross compiling, and
> /opt/vc/include otherwise.
> 
>  # The OPENGL header is a public dependency of Qt5::Gui:
>  set_property(TARGET Qt5::Gui APPEND PROPERTY
>      INTERFACE_INCLUDE_DIRECTORIES ${Qt5Gui_OPENGL_INCLUDE_DIRS})
> 
> The problem scenario is when generating include dirs without using
> find_path, but just getting the list from qmake. Eg, on the Raspberry Pi it
> is not enough to have /opt/vc/include to use the egl headers, even though
> 
>  /opt/vc/include/EGL/egl.h
> 
> exists. Some dependencies of that header are in
> 
>  /opt/vc/include/interface/vcos/pthread
> 
> and another location. I'm pretty sure the headers on the Pi are buggy, but
> the end result is that that dir also has to be in the include directories
> if we want to include EGL/egl.h. All such directories are already listed
> in qmake mkspecs
> 
>  https://qt.gitorious.org/qt/qtbase/blobs/HEAD/mkspecs/devices/linux-rasp-p
> i-g++/qmake.conf
> 
> so, I'm generating something like
> 
>  set(Qt5Gui_EGL_INCLUDE_DIRS
>     ${CMAKE_FIND_ROOT_PATH}/opt/vc/include
>     ${CMAKE_FIND_ROOT_PATH}/opt/vc/include/interface/vcos/pthreads
>     ${CMAKE_FIND_ROOT_PATH}/opt/vc/include/interface/vmcs_host/linux
>  )

In general CMAKE_FIND_ROOT_PATH is a list, then this would be a bug.
Does the generated toolchain file ensure that it is not a list ?

Alex



More information about the cmake-developers mailing list