- m4/python.m4: use version_info for Python 3.10 version string
- configure.ac: find Python 3.10
Tested on the openSUSE gpgme build: https://build.opensuse.org/request/show/941405
Format sys.version_info[:2] instead of cutting it from sys.version[:3]
as Python versions >= 3.10 have more than 3 characters for their version
string. Bump minimum Python version to 2.1 because the new
ax_python_devel specifies this.
See also Mailinglist https://lists.gnupg.org/pipermail/gnupg-devel/2021-December/035007.html
Thank you for submitting the patch.
I realized that m4/python.m4 is our local version, which originated from Automake.
The local change was added to support the fourth argument. This 4th argument was introduced to support multiple versions of Python.
Currently, generated configure script is somehow large, because AM_PATH_PYTHON is generated by m4_foreach.
I think that we need some improvement here, as (IIUC) the intention here is not supporting binding for all versions of python installed, but supporting binding for python2-if-any and python3 (just up to two versions).
I'd suggest the following way:
- removing our local python.m4 but using automake's standard python.m4 (which already has a fix for version detection)
- No use of m4_foreach, but put two invocations of AM_PATH_PYTHON, by 2.7 and 3.4 (specifying the minimum version)
I am not sure if you assumption about the intention is correct. After all, the openSUSE rpm build does use it for creating binding packages for all available python3 versions. If you remove the functionality to find all available versions ("flavors" in the openSUSE rpm packager lingo), the RPM build would need to introduce separate calls of configure and make.
The new revision uses the python.m4 version from automake 1.16.5 and keeps Werner's modifications with the 4th parameter.
See also https://dev.gnupg.org/T3354 and https://dev.gnupg.org/rMff6ff616aea6f59b7f2ce1176492850ecdf3851e
Tested here: https://build.opensuse.org/request/show/942350
@bnavigator Would it be possible to also add support for 3.11 and 3.12 here? That way this fix is a lot more futureproof.
@werner Seeing as you seem to be actively maintaining this project: is there any way to move this forward? This is breaking quite a few builds of development environments for my company and we are now applying similar patches ourselves but it would be nice to get this merged upstream.
That's why I added some tags and also set me a reminder. We will try to get this into the next GPGME release we plan for this month.