[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: allow the 'python' used to run to be configured

From: Adam Williamson
Subject: Re: Patch: allow the 'python' used to run to be configured
Date: Tue, 17 Jul 2018 12:35:42 -0700
User-agent: Evolution 3.29.3 (3.29.3-1.fc29)

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:
> > > 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 <address@hidden>
> > 
> > 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
> 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 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 already uses the PYTHON
env var - setting it if it was not set already - and then calls

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, would be considered, when using All the
'discovery' bits of AM_PATH_PYTHON wouldn't be used: if you just call
'' 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 *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 and for running But I
figured I should point it out.

With that in mind, I'm attaching the updated patch in git format.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net

Attachment: 0001-Use-AM_PATH_PYTHON-to-determine-interpreter-for-gent.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]