mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-05-23 22:58:10 +08:00
build(cmake): pin Python3 find strategy to LOCATION
find_package(Python3) defaults to the VERSION strategy, which prefers the newest Python it finds anywhere on the host over the one we set up for the build. On the macOS runner this caused cmake to pick the Homebrew python@3.14 even though setup-python had exported Python3_ROOT_DIR pointing at the venv where PX4 deps (kconfiglib, empy 3.x, etc.) were installed, and configure failed at the kconfig import. Set Python3_FIND_STRATEGY=LOCATION before find_package so cmake honors Python3_ROOT_DIR/PATH ordering -- the same first-match behaviour the legacy PythonInterp module had -- and prefer an active VIRTUAL_ENV when one is set. Signed-off-by: Nuno Marques <n.marques21@hotmail.com>
This commit is contained in:
@@ -173,6 +173,19 @@ set(config_module_list)
|
||||
set(config_kernel_list)
|
||||
|
||||
# Find Python
|
||||
#
|
||||
# Use LOCATION strategy so cmake picks the first Python3 it finds on
|
||||
# PATH (matching the legacy PythonInterp behavior) instead of the newest
|
||||
# system-wide version. Without this, CI runners that install PX4's
|
||||
# Python deps into one interpreter (e.g. the venv on macOS, or the
|
||||
# setup-python interpreter on Windows) but also have a newer system
|
||||
# Python on PATH (Homebrew python@3.14, MSYS2 mingw64 python) end up
|
||||
# configuring CMake with the wrong interpreter and fail at the
|
||||
# kconfiglib import in cmake/kconfig.cmake.
|
||||
set(Python3_FIND_STRATEGY LOCATION)
|
||||
if(DEFINED ENV{VIRTUAL_ENV})
|
||||
set(Python3_FIND_VIRTUALENV FIRST)
|
||||
endif()
|
||||
find_package(Python3 3 COMPONENTS Interpreter)
|
||||
# We have a custom error message to tell users how to install python3.
|
||||
if(NOT Python3_Interpreter_FOUND)
|
||||
|
||||
Reference in New Issue
Block a user