Hi Martin, >>>> * If we now have an (even optional) dependency on python/pytest, this >>>> (with the exact versions and use) needs to be documented in >>>> install.texi. >>> >>> Done that. >> +be installed. Some optional tests also require Python3 and pytest >> module. >> It would be better to be more specific here. Or would Python 3.0 and >> pytest 2.0.0 do ;-) > > I would leave it as it is. Python3 is a well established term. About pytest:
... but unfortunately not exactly precise beyond distinguishing between Python 2.x and 3.x. I'd specificially asked about 3.0 because IIRC the early 3.x versions were not only incompatible with 2.7, but even among themselves. Don't remember when this finally stabilized. > I don't know how to investigate a minimal version right now. It needn't necessarily be a minimal version, it could be one known to work (and worded appropriately to indicate that's what it is, not a minimum). E.g. from what's bundled with Solaris 11.3, I know that pytest 2.6.4 does work (apart from the python3 vs. python3.4 issue). >>>> * On to the implementation: your test for the presence of pytest is >>>> wrong: >>>> set result [remote_exec host "pytest -m pytest --version"] >>>> has nothing to do with what you actually use later: on all of Fedora >>>> 29, Ubuntu 20.04, and Solaris 11.4 (with a caveat) pytest is Python >>>> 2.7 based, but you don't check that. It is well possible that pytest >>>> for 2.7 is installed, but pytest for Python 3.x isn't. >>>> Besides, while Solaris 11.4 does bundle pytest, they don't deliver >>>> pytest, but only py.test due to a conflict with a different pytest from >>>> logilab-common, cf. https://github.com/pytest-dev/pytest/issues/1833. >>>> This is immaterial, however, since what you actually run is >>>> spawn -noecho python3 -m pytest --color=no -rA -s --tb=no >>>> $srcdir/$subdir/$pytest_script >>>> So you should just run python3 -m pytest --version instead to check >>>> for the presence of the version you're going to use. >>>> Btw., there's a mess with pytest on Fedora 29: running the above gives >>> >>> I must confirm this is mess. I definitely don't want to support Python2 and >>> I think >>> the best way would be to use 'env python3', hope it's portable enough. >>> @David: What do you think? >> As I mentioned, it's not: Solaris 11.3 has no python3, only (for the 3.x >> series) python3.4. >> However, I don't understand what you expect to gain from running >> $ env python3 >> rather than just >> $ python3 >> (or a suitable Python 3.x version by any name)? > > All right, let's replace it just with 'python3'. > >> I just had a quick look and the autoconf-archive has AX_PYTHON which >> claims to do that: >> https://www.gnu.org/software/autoconf-archive/ax_python.html >> Unfortunately, it doesn't know about Python 3.8+ yet. I think we can do better than hardcoding python3 here. If it were only for a quirk of an older Solaris version (11.3) which misses the python3 name, together with one (or soon two) optional testcases, I wouldn't care much. When looking at a VM with FreeBSD 12.2 (the current release), it took quite some searching to find how to get python2 and python3 commands installed, and I suspect those are not they only ones where it's either difficult or missing completely. Given that David also plans to use python3, we could use another approach: Rather than relying on an obscure/unmaintained macro from the autoconf-archive, automake includes AM_PATH_PYTHON which allows to specify a minimum version and knows about python2, python3, and python[23].x names. While the version of our current prerequisite, Automake 1.15.1, has a hardcoded list going up to python3.5 only, the git version has removed that limitation. What we should do to get this right is: * import that git automake m4/python.m4 into our toplevel config * call AM_PATH_PYTHON appropriately from gcc/configure.ac * record the resulting python path in site.exp * use it from there e.g. in gcov.exp This way we're future-proof for all possible uses of python3, rather than fiddling with the issue over and over again. I'm sorry to burden you with this, but given that you're the first to follow through with using python3 in the core of gcc rather than in some contrib script, we should get things right now if reasonably possible. The rest of the patch looks good now and passed my testing. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University
