There is subtle difference between our CTNG_PYTHON and the AX_PYTHON on
which it is based. The latter uses AC_CHECK_PROGS() which sets
PYTHON_BIN to the name of the executable. We use AC_PATH_PROGS() which
sets PYTHON_BIN to the full path of the executable.
Because the name of the executable is the same as the library AX_PYTHON
uses this when looking for the library with AC_CHECK_LIB() which magics
itself into a linker flag like `-lpython3.11` but our version ends up
with a nonsensical `-l/usr/bin/python3.11` so the check fails and we
keep iterating repeating the same wrong check for every tested python
version.
We can't just switch to using AC_CHECK_PROGS() because we do want to use
the variable set by AC_PATH_PROGS() to set the full path in paths.sh.
Ultimately we could probably switch to using the upstream AX_PYTHON
macro (https://www.gnu.org/software/autoconf-archive/ax_python.html) and
figure out a better way of getting the full path of the exectuable but
for now add an extra AC_CHECK_PROGS() to set a different variable and
use that for AC_CHECK_LIB().
Signed-off-by: Chris Packham <judge.packham@gmail.com>
We use the information from various configure time checks to populate
paths.sh. The paths used are all absolute except for the python binary.
In the switch to a more comprehensive check for python by commit
fa05153e ("Make checking for python more predictable.") we ended up
using AC_CHECK_PROGS which checks for the program on the path and sets
the variable to the name of the program. This makes python inconsistent
with the other programs and seems to cause problems for MSYS2. Use
AC_PATH_PROGS instead which does the same check but sets the variable to
the absolute name of the program
Fixes#2047
Signed-off-by: Chris Packham <judge.packham@gmail.com>
