The new FindPython-based variant of the CMake scripts caches information about the chosen Python version that can become stale. For example, suppose I configure a simple pybind11-based project as follows ``` cmake -S . -B build -GNinja -DPython_ROOT=<path to python 3.8> ``` which will generate `my_extension.cpython-38-x86_64-linux-gnu.so`. A subsequent change to the python version like ``` cmake -S . -B build -GNinja -DPython_ROOT=<path to python 3.9> ``` does not update all necessary build system information. In particular, the compiled file is still called `my_extension.cpython-38-x86_64-linux-gnu.so`. This commit fixes the problem by detecting changes in `Python_EXECUTABLE` and re-running Python as needed. Note that the previous way of detecting Python does not seem to be affected, it always specifies the right suffix.
| Name |
Last commit
|
Last Update |
|---|---|---|
| .. | ||
| FindCatch.cmake | Loading commit data... | |
| FindEigen3.cmake | Loading commit data... | |
| FindPythonLibsNew.cmake | Loading commit data... | |
| check-style.sh | Loading commit data... | |
| cmake_uninstall.cmake.in | Loading commit data... | |
| libsize.py | Loading commit data... | |
| make_changelog.py | Loading commit data... | |
| pybind11Common.cmake | Loading commit data... | |
| pybind11Config.cmake.in | Loading commit data... | |
| pybind11NewTools.cmake | Loading commit data... | |
| pybind11Tools.cmake | Loading commit data... | |
| pyproject.toml | Loading commit data... | |
| setup_global.py.in | Loading commit data... | |
| setup_main.py.in | Loading commit data... |