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

[Alexander Neundorf]

On Tuesday 16 April 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Friday 12 April 2013, Stephen Kelly wrote:
> >> I found out what the problem is. CMake doesn't add the sysroot to the
> >> link line, so that's why the linker is not finding the library. It was
> >> searching in my native root and not finding them.
> >> 
> >>  set(CMAKE_CXX_LINK_FLAGS
> >>  
> >>    "${CMAKE_CXX_LINK_FLAGS} --sysroot=${CMAKE_FIND_ROOT_PATH}")
> >> 
> >> Is there a reason CMake does not do something like the above already?
> > 
> > I don't think there's a reason that this is not done, except that nobody
> > has done it yet ;-)
> > So this should be somewhere inside a if(CMAKE_CROSSCOMPILING) in Linux-
> > GNU.cmake maybe ?
> 
> It needs special handling in c++ actually. I'll work on it. If
> CMAKE_FIND_ROOT_PATH can be a list, then we'll need a new variable like
> CMAKE_SYSROOT (which is also relevant to find_* commands) which is not a
> list.

That was the intention of CMAKE_FIND_ROOT_PATH, really.
When we added this in 2007, I think CMAKE_PREFIX_PATH did not exist yet (this 
was still 2.4.x on the way to 2.6.0).
So CMAKE_FIND_ROOT_PATH had to be a list, the list of directories where stuff 
for the target can be found.
Maybe today this could be done differently.
Let's say CMAKE_FIND_ROOT_PATH would be only one directory (sysroot), which is 
set so that it points to the target file system hierarchy.
The additional directories which need to be searched could today maybe also be 
listed in CMAKE_PREFIX_PATH.
The idea was that somewhere is the target file system, and the developer may 
have an additional directory with libs for hos target, maybe in his home.
Ok, this would ignore the separation between target and host, which is 
currently quite clear with CMAKE_FIND_ROOT_PATH vs. CMAKE_PREFIX_PATH.

Anyway, before adding another cmake variable this should be thought through 
well.

Alex