[cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

Clinton Stimpson clinton at elemtech.com
Thu Jul 30 11:20:54 EDT 2015


On Thursday, July 30, 2015 10:56:02 AM Brad King wrote:
> On 07/30/2015 09:29 AM, Pascal Bach wrote:
> > CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support
> > something like NATIVE and TARGET that one could use to choose where
> > to look for files.
> > This way every find_* call could explicitly tell if it wants a host
> > or a target version.
> 
> Are you proposing new keyword arguments to find_* commands to specify
> this?  The problem is that find modules don't necessarily know which
> kind of binary the application wants.  That is why we have the
> CMAKE_FIND_ROOT_PATH_MODE_<type> variables.
> 
> The existing CMAKE_FIND_ROOT_PATH* and CMAKE_SYSROOT options have been
> sufficient for most packages for a long time.  We regularly get
> complaints that FindPythonLibs does not ask the python executable
> where to get its libraries, and our answer every time is that it is
> wrong to do that for cross compiling.  FindQt4 is making that mistake,
> and that is the cause of these troubles.
> 
> FindQt4 should be taught not to ask qmake for anything when cross
> compiling.

FindQt4 supports 2 use cases when cross compiling.

1. One Qt installation with a mix of native and non-native files.

2. Two Qt installations, one native and one non-native.  In this case, qmake 
may still be queried to find other tools, but CMAKE_FIND_ROOT_PATH is used to 
find the non-native includes and libraries.

The second case is what you are asking for, right?

This why I previously suggested changing 
from
SET(CMAKE_FIND_ROOT_PATH /sysroot/arm ...)
to 
SET(CMAKE_FIND_ROOT_PATH /sysroot/arm/usr ...)

Because its a find root, not a sysroot.

Clint



More information about the cmake-developers mailing list