Find newer Python using old FindPython

Andrej730 · October 7, 2025, 8:54am

In my cmake I fetch a couple Python components - Development, Interpreter and for simplicity I wanted to provide Python installation by just prefixing the PATH (e.g. -DCMAKE_PREFIX_PATH="/my/install/python-3.13.6") instead of providing 3 variables explicitly (Python_INCLUDE_DIR, Python_LIBRARY, Python_EXECUTABLE).

Which does work for Python 3.9-3.12, but cmake fails to find it in case of Python 3.13.

Investigating, I’ve learned that Python 3.9-3.12 work because FindPython manages to find python python3.12-config and it’s used to deduce libraries path later.
It also fallbacks to find_library search with debug path hints, but again, it won’t suceed because python3.13.a is not present among the NAMES.

And in my case the system cmake is 3.26.5 and apparently the list of config files to search is hardcoded

  find_program called with the following settings:

    VAR: _Python_CONFIG
    NAMES: "python3.12-config"
           "python3.11-config"
           "python3.10-config"
           "python3.9-config"
           "python3.8-config"
           "python3.7-config"
           "python3.6-config"
           "python3.5-config"
           "python3.4-config"
           "python3.3-config"
           "python3.2-config"
           "python3.1-config"
           "python3.0-config"

Which comes from (ref):

if (_${_PYTHON_PREFIX}_REQUIRED_VERSION_MAJOR EQUAL "3")
  set(_${_PYTHON_PREFIX}_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0)
elseif (_${_PYTHON_PREFIX}_REQUIRED_VERSION_MAJOR EQUAL "2")
  set(_${_PYTHON_PREFIX}_VERSIONS 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0)
else()

And since Python 3.13 didn’t existed at the time, it’s not listed in the list of versions and it fails to find it’s python3.13-config and fails to find Python in general.

Providing -DPython_ROOT_DIR (though it would be less desirable, since it adds a special variable, instead of just prefixing PATH) doesn’t work too.

So I guess the only solution is to provide all 3 variables mentioned above.
I guess this kind of situation will keep reoccurring each year with new Python coming up, so if user’s script that’s using cmake is planning to support the most recent Python versions, then they should avoid relying on prefixing PATH and provide all variables explicitly.

Perhaps there could be more general solution? I’ve also noticed that Python installation includes in bin not just python3.13-config, but non-version-specificpython3-config, which in theory FindPython could search for too and this would allow finding Python versions from the future.

PS With that being said, I’ve only tested finding 3.13 on cmake 3.26.5. It’s possibly that this issue is resolved in newer cmake (e.g. maybe now it’s possible to find 3.15 by using current FindPython), but couldn’t find the discussion about this.

Andrej730 · October 7, 2025, 11:57am

Investigating some more, it seems python3-config doesn’t provide a direct way to get version with --version or something.

github.com/python/cpython

Misc/python-config.sh.in

134ff810c


      
          # Use sed to fix paths from their built-to locations to their installed-to
          # locations. Keep prefix & exec_prefix using their original values in case
          # they are referenced in other configure variables, to prevent double
          # substitution, issue #22140.
          prefix="@prefix@"
          exec_prefix="@exec_prefix@"
          exec_prefix_real=${prefix_real}
          includedir=$(echo "@includedir@" | sed "s#$prefix#$prefix_real#")
          libdir=$(echo "@libdir@" | sed "s#$prefix#$prefix_real#")
          CFLAGS=$(echo "@CFLAGS@" | sed "s#$prefix#$prefix_real#")
          VERSION="@VERSION@"
          LIBM="@LIBM@"
          LIBC="@LIBC@"
          SYSLIBS="$LIBM $LIBC"
          ABIFLAGS="@ABIFLAGS@"
          LIBS="@LIBPYTHON@ @LIBS@ $SYSLIBS"
          LIBS_EMBED="-lpython${VERSION}${ABIFLAGS} @LIBS@ $SYSLIBS"
          BASECFLAGS="@BASECFLAGS@"
          LDLIBRARY="@LDLIBRARY@"
          OPT="@OPT@"
          PY_ENABLE_SHARED="@PY_ENABLE_SHARED@"

Apparently it would be only possible to get it by parsing it either from one of it’s options (e.g. --includes returns /include/python3.13) or from VERSION="3.13" line in the file.

Both approaches seems a bit fragile for FindPython to use them

And also on Windows there’s no pythonx.xx-config.exe (though currently cmake is still searching for it using find_program - probably just an overlook) and not sure what would be the alternative for this system.