[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30616: automake-1.16: aclocal is unable to process AM_PATH_PYTHON wi
From: |
Mathieu Lirzin |
Subject: |
bug#30616: automake-1.16: aclocal is unable to process AM_PATH_PYTHON with variable as value |
Date: |
Sat, 03 Mar 2018 12:32:16 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Thomas Deutschmann <address@hidden> writes:
> the problem is line
>
>> m4_define_default([am_py_min_ver], m4_ifval([$1], [$1], [2.0]))
>
> Code like
>
>> AM_PATH_PYTHON([$PYTHON_VERSION])
>
> will result in "am_py_min_ver" set to "$PYTHON_VERSION" which is
> obviously not a valid value. I.e. the passed argument isn't expanded
> when used in the macro.
>
> However, I don't understand why we need the dynamic in the list
> creation. From my understanding, GNU Pyconfigure, the implementation
> source, provided a macro which requires to set lower and upper bound
> ("PC_INIT([MIN_VER], [MAX_VER])"). But given that the AM_PATH_PYTHON
> public function wasn't changed, we don't need to (better: cannot)
> generate the list dynamically.
You are right that the solution chosen by Pyconfigure solves a different
issue because of the upper bound.
> So I would recommend to change this line to
>
>> m4_define_default([am_py_min_ver], [2.0])
>
> This fixes the problem in cryptsetup, util-linux and PythonMagick for
> me. And the check still works. I.e. when I remove the minimum Python
> version or newer on my system, configure fails like expected.
Given the other portability problems the faulty commit has, I think
simply reverting it as suggested by Eric Blake seems better.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
- bug#30616: automake-1.16: aclocal is unable to process AM_PATH_PYTHON with variable as value,
Mathieu Lirzin <=