On Fri, 2018-07-06 at 13:19 -0700, Adam Williamson wrote:
> On Fri, 2018-07-06 at 19:25 +0200, Daniel Kiper wrote:
> > On Wed, Jul 04, 2018 at 10:08:53AM -0700, Adam Williamson wrote:
> > > gentpl.py is python2/3-agnostic, but there's no way to cause it
> > > to be run with any interpreter other than 'python', it's just
> > > hard-coded into Makefile.common that way. Adjust that to allow
> > > a make variable PYTHONBIN to be set to the desired interpreter.
> > > This will make it easier in situations where we specifically
> > > want to build with 'python2' or 'python3' or whatever.
> > >
> > > Signed-off-by: Adam Williamson <awill...@redhat.com>
> >
> > Thanks for the patch. However, I think that the configure should find
> > correct python binary and set PYTHON variable (instead of PYTHONBIN)
> > in the Makefile (good example is BUILD_CC variable in Makefile.in).
>
> That's possible, but it depends what you mean by "correct", doesn't it?
> There could be many python interpreters installed on a system; which
> are we to assume is "correct"?
>
> We could make it configurable with some sort of default heuristic, I
> guess, I was just going for a simple patch approximately in line with
> what was done for autogen.sh for now. (And I wouldn't want to reinvent
> python interpreter discovery, which has been invented enough times
> already; if we were to go that route it'd probably make sense to use an
> existing autoconf extension or something).
So I've just been looking into this, and it's actually very easy to do
using AM_PATH_PYTHON, provided by autoconf. However, there's a rather
funny wrinkle for grub's particular build process. AM_PATH_PYTHON has a
documented behaviour where, if the 'PYTHON' env var is set when
autoconf is run, it will *only* consider the value that env var is set
to as a candidate for the Python interpreter - it won't do its usual
attempt to discover one. And grub's autogen.sh already uses the PYTHON
env var - setting it if it was not set already - and then calls
autoreconf!
So the practical effect of just applying this patch would be that only
'python', or whatever the env var PYTHON is set to when running
autogen.sh, would be considered, when using autogen.sh. All the
'discovery' bits of AM_PATH_PYTHON wouldn't be used: if you just call
'autogen.sh' without setting PYTHON, but your Python binary is called
'python3' or 'python2.7' or whatever, it won't work.
This seems a bit funny, but I'm not sure if it's really a
*problem*...because autogen.sh *itself* will only work if whatever
value PYTHON is set to is a working Python interpreter, anyway. We
could in fact argue that the consequence is quite nice as it makes
everything sort of consistent: whatever PYTHON is set to will be the
interpreter used both by autogen.sh and for running gentpl.py. But I
figured I should point it out.
With that in mind, I'm attaching the updated patch in git format.
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
From 5fc0bb5f16a4189aa9581ebca4ea3abbc5c96593 Mon Sep 17 00:00:00 2001
From: Adam Williamson <awill...@redhat.com>
Date: Wed, 4 Jul 2018 09:55:52 -0700
Subject: [PATCH] Use AM_PATH_PYTHON to determine interpreter for gentpl.py
gentpl.py is python2/3-agnostic, but there's no way to cause it
to be run with any interpreter other than 'python', it's just
hard-coded into Makefile.common that way. Adjust that to use
AM_PATH_PYTHON (provided by automake) to find an interpreter
and run gentpl.py with that instead. This makes grub buildable
when `python` does not exist (but rather `python3` or `python2`
or `python2.7`, etc.) Minimum version is set to 2.6 as this is
the first version with `__future__.print_function` available.
Note, AM_PATH_PYTHON respects the PYTHON environment variable
and will treat its value as the *only* candidate for a valid
interpreter if it is set - when PYTHON is set, AM_PATH_PYTHON
will not try to find any alternative interpreter, it will only
check whether the interpreter set as the value of PYTHON meets
the requirements and use it if so or fail if not. This means
that when using grub's `autogen.sh`, as it too uses the value
of the PYTHON environment variable (and if it is not set, just
sets it to 'python') you cannot rely on AM_PATH_PYTHON
interpreter discovery. If your desired Python interpreter is
not just 'python', you must set the PYTHON environment variable,
e.g. 'PYTHON=/usr/local/bin/python3 ./autogen.sh'. The specified
interpreter will then be used both by autogen.sh itself and by
the autotools-driven build scripts.
Signed-off-by: Adam Williamson <awill...@redhat.com>
---
conf/Makefile.common | 4 ++--
configure.ac | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/conf/Makefile.common b/conf/Makefile.common
index 311da61c6..f761f7224 100644
--- a/conf/Makefile.common
+++ b/conf/Makefile.common
@@ -128,11 +128,11 @@ BUILT_SOURCES =
.PRECIOUS: $(top_srcdir)/Makefile.util.am
$(top_srcdir)/Makefile.util.am: $(top_srcdir)/gentpl.py $(top_srcdir)/Makefile.util.def $(top_srcdir)/Makefile.utilgcry.def
- python $^ > $@.new || (rm -f $@.new; exit 1)
+ $(PYTHON) $^ > $@.new || (rm -f $@.new; exit 1)
mv $@.new $@
.PRECIOUS: $(top_srcdir)/grub-core/Makefile.core.am
$(top_srcdir)/grub-core/Makefile.core.am: $(top_srcdir)/gentpl.py $(top_srcdir)/grub-core/Makefile.core.def $(top_srcdir)/grub-core/Makefile.gcry.def
if [ "x$$GRUB_CONTRIB" != x ]; then echo "You need to run ./autogen.sh manually." >&2; exit 1; fi
- python $^ > $@.new || (rm -f $@.new; exit 1)
+ $(PYTHON) $^ > $@.new || (rm -f $@.new; exit 1)
mv $@.new $@
diff --git a/configure.ac b/configure.ac
index c7888e40f..596f7c3f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -337,6 +337,7 @@ gl_EARLY
AC_PROG_CXX
AM_PROG_CC_C_O
AM_PROG_AS
+AM_PATH_PYTHON([2.6])
# Must be GCC.
test "x$GCC" = xyes || AC_MSG_ERROR([GCC is required])
--
2.18.0.rc2
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
