[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