Hi,
When using find_package (<name> NO_MODULE) while cross-compiling,
cmake may find an existing <name>Config.cmake in the host root path if
<name>Config.cmake is not available in the target root path.
For example let's say that I have Qt5 project in my host Linux box, which
provides a /usr/lib/cmake/.../Qt5WidgetsConfig.cmake.
In my cmake project I use: find_package (Qt5Widgets NO_MODULE), everything goes
as planned.
Now I want to cross-compile using MinGW-w64, I install qt5 in my mingw target
root, so I have a /usr/i686-w64-mingw32/lib/cmake/.../Qt5WidgetsConfig.cmake
I set CMAKE_FIND_ROOT_PATH to /usr/i686-w64-mingw32 and stuff via a toolchain
file, and everything goes fine too.
No if I remove the qt5 target package for mingw, or it is unavailable in the
first place, cmake prefers the host qt5 config file, and the compilation fails.
I found a workaround, which is to not let cmake use host rules to find
<name>Config.cmake in the case of cross-compiling:
if (CMAKE_CROSSCOMPILING)
set (NO_MODULE_ARGS NO_MODULE NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH)
endif ()
find_package (Qt5Widgets ${NO_MODULE_ARGS})
Would there be a smarter way to do this instead of invading each CMakeLists
that uses a find_package relying on package-provided cmake configs ?
--
Julien Schueller
Phimeca Engineering
www.phimeca.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
