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:
Nuno Marques
2026-05-07 16:52:08 -07:00
parent ce4db3ccf6
commit 6dc436811e
+13
View File
@@ -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)