Hello, Moritz Klammler <mor...@klammler.eu> 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