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 <cr...@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
