OSDN Git Service

configure: Look for auxiliary Python installations
authorJohn Snow <jsnow@redhat.com>
Fri, 10 Feb 2023 00:31:43 +0000 (01:31 +0100)
committerPaolo Bonzini <pbonzini@redhat.com>
Mon, 27 Feb 2023 10:01:30 +0000 (11:01 +0100)
commitfee6d4124a470a541eeb51c59ee2b4aea09c6c49
tree5b6339dcc0bd0704a40c9ed06d2c28bfe9c42d0f
parent462a65678e0fc15f924bf0f9f4d384fc18487b9b
configure: Look for auxiliary Python installations

At the moment, we look for just "python3" and "python", which is good
enough almost all of the time. But ... if you are on a platform that
uses an older Python by default and only offers a newer Python as an
option, you'll have to specify --python=/usr/bin/foo every time.

We can be kind and instead make a cursory attempt to locate a suitable
Python binary ourselves, looking for the remaining well-known binaries.

This configure loop will prefer, in order:

1. Whatever is specified in $PYTHON
2. python3
3. python
4. python3.11 down through python3.6

Notes:

- Python virtual environment provides binaries for "python3", "python",
  and whichever version you used to create the venv,
  e.g. "python3.8". If configure is invoked from inside of a venv, this
  configure loop will not "break out" of that venv unless that venv is
  created using an explicitly non-suitable version of Python that we
  cannot use.

- In the event that no suitable python is found, the first python found
  is the version used to generate the human-readable error message.

- The error message isn't printed right away to allow later
  configuration code to pick up an explicitly configured python.

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
configure