[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28160: Support newer version of python
From: |
Mathieu Lirzin |
Subject: |
bug#28160: Support newer version of python |
Date: |
Fri, 22 Sep 2017 11:08:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
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