core/pkg-cmake: better way to pass our CMAKE_MODULE_PATH
PATCH v2 1/1 core/pkg-cmake: better way to pass our CMAKE_MODULE_PATH
Currently, we tell cmake where to look for our own custom platform description by passing the path to the moduls directory on the command line.
However, this causes two different problems.
First, some packages simply set CMAKE_MODULE_PATH in their CMakeList.txt, thus overriding our own path, and then our platform description is not found.
Second, cmake may internally call sub-cmake (e.g. in the try_compile macro), but the CMAKE_MODULE_PATH is not automatically passed down in this case.
For the first problem, we could hunt down and fix all offenders, but this is an endless endeavour, especially since packagers are told to do so on the cmake wiki [0]:
CMAKE_MODULE_PATH
tell CMake to search first in directories listed in CMAKE_MODULE_PATH when you use FIND_PACKAGE() or INCLUDE() SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/MyCMakeScripts) FIND_PACKAGE(HelloWorld)
The second problem could be solved by passing yet another variable on the command line, that tells cmake to explicitly pass arbitrary variables down to sub-cmake calls:
-DCMAKE_TRY_COMPILE_PLATFORM_VARIABLES=CMAKE_MODULE_PATH
However, this only covers the case of try_compile. Even though no other case is known yet, we'd still risk missing locations where we would need to propagate CMAKE_MODULE_PATH, even some where we'd have no solution like for try_compile.
Instead, ngladitz on IRC suggested that CMAKE_MODULE_PATH be set directly from the toolchain file.
And indeed this fixes both problems explained above.
So be it.
[0] https://cmake.org/Wiki/CMake_Useful_Variables
---
Changes v1 -> v2:
- fix really bad typo in title
--- package/pkg-cmake.mk | 1 - support/misc/toolchainfile.cmake.in | 4 ++++ 2 files changed, 4 insertions(+), 1 deletion(-)
package/pkg-cmake.mk +0 -1
@@ -87,7 +87,6 @@ define $(2)_CONFIGURE_CMDS PATH=$$(BR_PATH) \ $$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \ -DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \ - -DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \ -DCMAKE_INSTALL_PREFIX="/usr" \ -DCMAKE_COLOR_MAKEFILE=OFF \ -DBUILD_DOC=OFF \
support/misc/toolchainfile.cmake.in +4 -0
@@ -10,6 +10,10 @@ # RELOCATED_HOST_DIR variable. string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR}) +# Point cmake to the location where we have our custom modules, +# so that it can find our custom platform description. +list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR}) + set(CMAKE_SYSTEM_NAME Buildroot) set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
Signature · 1 line
2.7.4
Thomas Petazzoni
AppliedPATCH v2 1/1 core/pkg-cmake: better way to pass our CMAKE_MODULE_PATH
Hello,
Quoted 53 lines · Yann E. MORIN
Currently, we tell cmake where to look for our own custom platform description by passing the path to the moduls directory on the command line.
However, this causes two different problems.
First, some packages simply set
CMAKE_MODULE_PATHin their CMakeList.txt, thus overriding our own path, and then our platform description is not found.Second, cmake may internally call sub-cmake (e.g. in the
try_compilemacro), but theCMAKE_MODULE_PATHis not automatically passed down in this case.For the first problem, we could hunt down and fix all offenders, but this is an endless endeavour, especially since packagers are told to do so on the cmake wiki [0]:
CMAKE_MODULE_PATH
tell CMake to search first in directories listed inCMAKE_MODULE_PATHwhen you useFIND_PACKAGE()orINCLUDE()SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/MyCMakeScripts)FIND_PACKAGE(HelloWorld)The second problem could be solved by passing yet another variable on the command line, that tells cmake to explicitly pass arbitrary variables down to sub-cmake calls:
-DCMAKE_TRY_COMPILE_PLATFORM_VARIABLES=CMAKE_MODULE_PATH
However, this only covers the case of
try_compile. Even though no other case is known yet, we'd still risk missing locations where we would need to propagateCMAKE_MODULE_PATH, even some where we'd have no solution like fortry_compile.Instead, ngladitz on IRC suggested that
CMAKE_MODULE_PATHbe set directly from the toolchain file.And indeed this fixes both problems explained above.
So be it.
[0] https://cmake.org/Wiki/CMake_Useful_Variables
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Samuel Martin <[email protected]>Cc J?rg Krause <[email protected]>Cc Ben Boeckel <[email protected]>Cc Baruch Siach <[email protected]>Cc Vicente Olivert Riera <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Arnout Vandecappelle <[email protected]>Cc Peter Korsgaard <[email protected]>
Quoted 3 lines
---
Changes v1 -> v2:
- fix really bad typo in title
Applied to master, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com