CMake configuration picks up Python 2 and 3 mixture if both are available
The CMake configuration uses two different techniques for finding an interpreter.
find_package(Python COMPONENTS Interpreter)
# Deprecated since version 3.12
find_package(PythonInterp)
The latter is more common in the code but has been deprecated since CMake 3.12. The former is used in a single place in Gaudi, but as stated in the CMake docs it preferably chooses Python 3!
This can lead to two interpreters being present in the configuration (e.g. if Python 2 is taken from LCG_96 but Python 3 is installed on the host).
$ grep -i python_executable:filepath Gaudi/build.x86_64-centos7-gcc8-dbg/CMakeCache.txt
PYTHON_EXECUTABLE:FILEPATH=/cvmfs/lhcb.cern.ch/lib/lcg/releases/LCG_96/Python/2.7.16/x86_64-centos7-gcc8-dbg/bin/python2.7
Python_EXECUTABLE:FILEPATH=/usr/bin/python3.6
This can cause problems in a Python 2 build as scan_dict_deps.py
is called with Python_EXECUTABLE
, and the environment for that interpreter may not have the required dependencies.1
Fix
We could use FindPython2
or FindPython3
explicitly, but I don't know how to dispatch to the correct one without first finding the interpreter we should be using (which is what FindPython
is supposed to do!).
Another option is to remove the check on CMAke version 3.12.
diff --git a/cmake/modules/EnableROOT6.cmake b/cmake/modules/EnableROOT6.cmake
index 63974ecfc..db6245b20 100644
--- a/cmake/modules/EnableROOT6.cmake
+++ b/cmake/modules/EnableROOT6.cmake
@@ -9,17 +9,10 @@ set(ROOT_ALL_TOOLS root rootcling genreflex)
# checks for computation of dependencies of dictionaries
if (CMAKE_GENERATOR MATCHES "Ninja")
- if(CMAKE_VERSION VERSION_LESS 3.12)
find_package(PythonInterp QUIET)
if (PYTHON_EXECUTABLE)
set(scan_dicts_deps ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_LIST_DIR}/scan_dict_deps.py)
endif()
- else()
- find_package(Python COMPONENTS Interpreter)
- if (TARGET Python::Interpreter)
- set(scan_dicts_deps Python::Interpreter ${CMAKE_CURRENT_LIST_DIR}/scan_dict_deps.py)
- endif()
- endif()
endif()
# Helper macro to discover the dependencies between components needed on Mac)
This has the advantage of being consistent with the Python CMake configuration everywhere else in Gaudi, but this technique has been deprecated.
/cc @rmatev
-
Concretely: on a machine with a standard Python 3 installation, building Gaudi with LCG_96 will throw an error about the
python3
interpreter not being able to find thesix
module, which is imported byscan_dict_deps.py
↩