From: Eduardo Habkost <ehabkost@redhat.com>
To: Cleber Rosa <crosa@redhat.com>
Cc: qemu-devel@nongnu.org, "Caio Carrara" <ccarrara@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Fam Zheng" <famz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/4] configure: keep track of Python version
Date: Fri, 9 Nov 2018 16:25:01 -0200 [thread overview]
Message-ID: <20181109182501.GY12503@habkost.net> (raw)
In-Reply-To: <2426066f-37b0-acb8-f5f9-02fec9b6d7fa@redhat.com>
On Fri, Nov 09, 2018 at 11:39:32AM -0500, Cleber Rosa wrote:
>
>
> On 11/9/18 10:49 AM, Eduardo Habkost wrote:
> > On Fri, Nov 09, 2018 at 10:07:07AM -0500, Cleber Rosa wrote:
> >> Some functionality is dependent on the Python version
> >> detected/configured on configure. While it's possible to run the
> >> Python version later and check for the version, doing it once is
> >> preferable. Also, it's a relevant information to keep in build logs,
> >> as the overall behavior of the build can be affected by it.
> >>
> >> Signed-off-by: Cleber Rosa <crosa@redhat.com>
> >> ---
> >> configure | 6 +++++-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure b/configure
> >> index 74e313a810..67fff0290d 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -1740,6 +1740,9 @@ if ! $python -c 'import sys; sys.exit(sys.version_info < (2,7))'; then
> >> "Use --python=/path/to/python to specify a supported Python."
> >> fi
> >>
> >> +# Preserve python version since some functionality is dependent on it
> >> +python_version=$($python -V 2>&1 | sed -e 's/Python\ //')
> >
> > What about:
> > $($python -c 'import sys;print(sys.version)')
> > ?
> >
> > It is very verbose, but I think that's a good thing.
> >
>
> Well, something like:
>
> '3.7.1 (default, Oct 23 2018, 18:19:07) \n[GCC 8.2.1 20180801 (Red Hat
> 8.2.1-2)]'
>
> Doesn't qualify as simply the Python *version*. The documentation[1]
> puts it clearly: "A string containing the version number of the Python
> interpreter plus additional information on the build number and compiler
> used. This string is displayed when the interactive interpreter is started."
>
> I can't see how the compiler used on the Python build, or the build
> date, can be significant to someone debugging the type of Python code
> that will be on QEMU.
No problem to me.
>
> >> +
> >> # Suppress writing compiled files
> >> python="$python -B"
> >>
> >> @@ -5918,7 +5921,7 @@ echo "LDFLAGS $LDFLAGS"
> >> echo "QEMU_LDFLAGS $QEMU_LDFLAGS"
> >> echo "make $make"
> >> echo "install $install"
> >> -echo "python $python"
> >> +echo "python $python ($python_version)"
> >> if test "$slirp" = "yes" ; then
> >> echo "smbd $smbd"
> >> fi
> >> @@ -6823,6 +6826,7 @@ echo "INSTALL_DATA=$install -c -m 0644" >> $config_host_mak
> >> echo "INSTALL_PROG=$install -c -m 0755" >> $config_host_mak
> >> echo "INSTALL_LIB=$install -c -m 0644" >> $config_host_mak
> >> echo "PYTHON=$python" >> $config_host_mak
> >> +echo "PYTHON_VERSION=$python_version" >> $config_host_mak
> >
> > The output of "python -V" and "sys.version" seems to be meant for
> > humans, not software. If we really want something to be used in
> > conditional makefile rules, I'd prefer to use sys.version_info.
> > e.g.:
> >
>
> "Python -V" is quite different from "sys.version". Indeed it includes
> the "Python " prefix, but that's all, everything else is the version number.
Is this a guarantee documented somewhere?
>
> > python_major_version="$($python -c 'import sys;print(sys.version_info[0])')"
> > echo "PYTHON_MAJOR_VERSION=$python_major_version"
> >
> >
>
> No, I'm actually interested in the other version components, not just
> the major version. As I tried to explain in another thread, differences
> from Python 3.0 to 3.4 are many, and from 3.4 to 3.6 and so on.
Do you have any examples in mind? I really doubt we will need to
look at the Python minor version number inside shell scripts or
makefiles.
>
> Then, we can either introduce "PYTHON_MAJOR_VERSION",
> "PYTHON_MINOR_VERSION", "PYTHON_RELEASE" of sorts, or just have a single
> dot separated version string.
A dot separated version string would work for me, too. I don't
mind the format that much, because I expect the new variable to
become unnecessary in the next year. :)
--
Eduardo
next prev parent reply other threads:[~2018-11-09 18:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-09 15:07 [Qemu-devel] [PATCH 0/4] Record Python version and misc test/CI fixes Cleber Rosa
2018-11-09 15:07 ` [Qemu-devel] [PATCH 1/4] configure: keep track of Python version Cleber Rosa
2018-11-09 15:49 ` Eduardo Habkost
2018-11-09 16:39 ` Cleber Rosa
2018-11-09 18:25 ` Eduardo Habkost [this message]
2018-11-09 19:09 ` Cleber Rosa
2018-11-09 19:51 ` Cleber Rosa
2018-11-09 21:25 ` Eduardo Habkost
2018-11-09 21:26 ` Eduardo Habkost
2019-08-22 16:48 ` Peter Maydell
2019-08-22 21:19 ` Cleber Rosa
2019-08-22 21:54 ` Eduardo Habkost
2019-08-23 13:40 ` Cleber Rosa
2019-08-23 13:44 ` Peter Maydell
2019-08-23 17:42 ` Cleber Rosa
2019-08-23 15:04 ` Eduardo Habkost
2019-08-23 17:44 ` Cleber Rosa
2018-11-09 15:07 ` [Qemu-devel] [PATCH 2/4] check-venv: use recorded " Cleber Rosa
2018-11-09 21:27 ` Eduardo Habkost
2018-11-09 15:07 ` [Qemu-devel] [PATCH 3/4] Travis CI: make specified Python versions usable on jobs Cleber Rosa
2018-11-09 15:52 ` Alex Bennée
2018-11-12 16:25 ` Eduardo Habkost
2018-11-09 19:34 ` Philippe Mathieu-Daudé
2018-11-09 19:39 ` Cleber Rosa
2018-11-12 16:23 ` Eduardo Habkost
2018-11-12 17:38 ` Cleber Rosa
2018-11-09 15:07 ` [Qemu-devel] [PATCH 4/4] check-help: visual and content improvements Cleber Rosa
2018-11-09 16:43 ` Eric Blake
2018-11-09 19:32 ` Philippe Mathieu-Daudé
2018-11-09 21:29 ` Eduardo Habkost
2018-11-12 17:51 ` Wainer dos Santos Moschetta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181109182501.GY12503@habkost.net \
--to=ehabkost@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=ccarrara@redhat.com \
--cc=crosa@redhat.com \
--cc=f4bug@amsat.org \
--cc=famz@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wainersm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).