bug#28160: Support newer version of python

[Mathieu Lirzin]

Hello,

Moritz Klammler <address@hidden> writes:

> On 09/15/2017 11:42 AM, Thomas Jahns wrote:
>> On 09/15/17 11:17, Mathieu Lirzin wrote:
>>> Instead of preemptively adding possible future version of Python that
>>> hopefully would be released, I would prefer a solution that removes the
>>> need to hard-code them.
>>>
>>> WDYT?
>> 
>> Why not parse PATH and filter what pathelem/python* returns for a
>> pattern like
>> 
>> python[0-9.]*
>> 
>> then test for executability and extract numerically highest (that's
>> probably the hardest part) suffix?
>> 
>> Regards, Thomas
>
>
> AFAIK, all versions of Python let you do
>
>     $ python -c 'import sys; print(sys.hexversion);'
>
> to print an integer that is increasing strictly monotonic between
> releases.  Might be a good way to combine testing whether an executable
> file really is a Python interpreter and finding the newest one among
> those.  Instead of parsing version numbers, you can then simply compare
> plain integers which is easy to do in the shell.
>
> On the other hand, the "hexversion" can be easily computed given a major
> and minor version number:
>
> https://docs.python.org/3.7/c-api/apiabiversion.html#apiabiversion

It seems that GNU Pyconfigure has already found a way to build that list
dynamically in m4.  Please see PC_PROG_PYTHON macro here:

  https://git.savannah.gnu.org/cgit/pyconfigure.git/tree/src/m4/python.m4

I am far from an m4 expert, so if someone is interested in porting that
macro to Automake, please step up.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37