On 1/15/21 1:28 PM, Rainer Orth wrote:
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 ;-)
Hello.
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've got this, but as Python 3.0 was released more than 10 years ago, I'm
leaving
Python3 for now. Feel free to propose a better wording.
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:
Where's a Python3 binary on a FreeBSD system?
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.
Feel free to propose a patch please.
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.
Sure, but we speak about an optional tests.
The rest of the patch looks good now and passed my testing.
I'm going to install the patch.
Martin
Rainer
