bug-automake
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]