On Fri, Feb 10, 2023 at 4:28 PM John Snow <jsnow@redhat.com> wrote:
> PS, while you're here, how does this new loop interfere with your "custom python specified" flag for meson? I think meson uses the version of python *it* detects and not the configure script identified one, right? Does that mean that e.g. the qapi generator gets run with the system default/meson version and not the config version?
Yes, if neither --python nor --meson are specified, then it could
happen that a different python is used during ninja's execution vs.
what is used for "other stuff" (docker cross compilers and other
Makefile invocations of $(PYTHON)).
The meson version of Python is guaranteed to be at least 3.7 as soon
as we update to 0.63.x (which will be Real Soon Now), but it's ugly.
The main issue I anticipate could be a problem when running from a
virtual environment, so perhaps we can force usage of the internal
meson if neither --python nor --meson are specified, and VIRTUAL_ENV
is set and $VIRTUAL_ENV/bin/meson does not exist?
diff --git a/configure b/configure
index 06bcd9031903..001a79a90170 100755
--- a/configure
+++ b/configure
@@ -870,8 +870,18 @@ fi
# Suppress writing compiled files
python="$python -B"
+has_meson() {
+ if test "${VIRTUAL_ENV:+set}" = set; then
+ # Ensure that Meson and Python come from the same virtual environment
+ test -x "$(VIRTUAL_ENV}/bin/meson" &&
+ test "$(command -v meson)" -ef "$(VIRTUAL_ENV}/bin/meson"
+ else
+ has meson
+ fi
+}
+
if test -z "$meson"; then
- if test "$explicit_python" = no && has meson && version_ge
"$(meson --version)" 0.63.0; then
+ if test "$explicit_python" = no && has_meson && version_ge
"$(meson --version)" 0.63.0; then
meson=meson
elif test "$git_submodules_action" != 'ignore' ; then
meson=git
I will include it when posting the final series.
> Do I need to adjust this loop to consider more binaries as "explicitly specified"?
I don't think it's a huge problem. Outside virtual environments, the
most likely setting is that Meson uses python3 which in turn is the
most recent python3.X, so it should be fine overall.
Though part of me thinks that your new loop is slightly overengineered
and we should just require /usr/bin/env python3 and call it a day.
Well, but that'd be a problem for CentOS 8, wouldn't it? python3 is gonna resolve to python3.6.