bug#51225: Possible bug in python.m4, automake 1.16.4+
bug#51225: Possible bug in python.m4, automake 1.16.4+
Am 17.10.21 um 04:30 schrieb Joshua Root:
On 2021-10-17 12:32 , Karl Berry wrote:
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670
However, this change leads to pkg-config .pc files containing the
variable name $PYTHON_PREFIX, not its content
I admit I didn't test much explicitly, but my understanding was that the
use of ${PYTHON_PREFIX} in various places instead of its value was
intentional, to allow for overriding at make time.
Thus, whatever the process is for creating .pc files, I guess it
may need to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.
The documentation mentions in several places that the variables set by
Automake are only really designed to be used in the Makefiles that it
generates. Using AC_SUBST to directly substitute them into other kinds
of files comes with the risk of exactly this kind of thing happening.
You could equally complain that some variables you want to use in the
.pc file are defined in terms of $prefix; except it just happens that
most .pc files already contain a prefix variable, so it works.
As Karl alluded to, if you want the fully expanded path, the .pc file
needs to be generated by make, not configure. If you don't do it that
way, the way these Makefile variables are defined will change and break
your non-Makefiles sometimes.
- Josh
Thank you for your explanation! So I guess xcb-proto needs to be fixed
then. I’ll report it to them. But I have a strong feeling that, as you
explained, this problem will come up again as more and more projects
start using automake >=1.16.4.
bug#51225: Possible bug in python.m4, automake 1.16.4+
Am 17.10.21 um 04:30 schrieb Joshua Root:
On 2021-10-17 12:32 , Karl Berry wrote:
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670
However, this change leads to pkg-config .pc files containing the
variable name $PYTHON_PREFIX, not its content
I admit I didn't test much explicitly, but my understanding was that the
use of ${PYTHON_PREFIX} in various places instead of its value was
intentional, to allow for overriding at make time.
Thus, whatever the process is for creating .pc files, I guess it
may need to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.
The documentation mentions in several places that the variables set by
Automake are only really designed to be used in the Makefiles that it
generates. Using AC_SUBST to directly substitute them into other kinds
of files comes with the risk of exactly this kind of thing happening.
You could equally complain that some variables you want to use in the
.pc file are defined in terms of $prefix; except it just happens that
most .pc files already contain a prefix variable, so it works.
As Karl alluded to, if you want the fully expanded path, the .pc file
needs to be generated by make, not configure. If you don't do it that
way, the way these Makefile variables are defined will change and break
your non-Makefiles sometimes.
- Josh
@Josh sorry, but only just now did I see you already sent a patch to
xcb-proto. This does solve the issue for me.
Anyway, thanks again to both of you! :)
bug#51225: Possible bug in python.m4, automake 1.16.4+
On 2021-10-17 12:32 , Karl Berry wrote:
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670
However, this change leads to pkg-config .pc files containing the
variable name $PYTHON_PREFIX, not its content
I admit I didn't test much explicitly, but my understanding was that the
use of ${PYTHON_PREFIX} in various places instead of its value was
intentional, to allow for overriding at make time.
Thus, whatever the process is for creating .pc files, I guess it
may need to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.
The documentation mentions in several places that the variables set by
Automake are only really designed to be used in the Makefiles that it
generates. Using AC_SUBST to directly substitute them into other kinds
of files comes with the risk of exactly this kind of thing happening.
You could equally complain that some variables you want to use in the
.pc file are defined in terms of $prefix; except it just happens that
most .pc files already contain a prefix variable, so it works.
As Karl alluded to, if you want the fully expanded path, the .pc file
needs to be generated by make, not configure. If you don't do it that
way, the way these Makefile variables are defined will change and break
your non-Makefiles sometimes.
- Josh
bug#51225: Possible bug in python.m4, automake 1.16.4+
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670
However, this change leads to pkg-config .pc files containing the
variable name $PYTHON_PREFIX, not its content
I admit I didn't test much explicitly, but my understanding was that the
use of ${PYTHON_PREFIX} in various places instead of its value was
intentional, to allow for overriding at make time.
Thus, whatever the process is for creating .pc files, I guess it
may need to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.
? --thanks for the report, karl.
bug#51225: Possible bug in python.m4, automake 1.16.4+
Hi,
in commit
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670
line 160 of python.m4
you changed the sed command so that am_cv_python_pythondir does not
contain the content of $PYTHON_PREFIX anymore but the variable name
$PYTHON_PREFIX. The same with $PYTHON_EXEC_PREFIX a couple of lines below.
For reference:
@@ -157,13 +224,13 @@ sys.stdout.write(sitedir)"`
case $am_cv_python_pythondir in
$am_py_prefix*)
am__strip_prefix=`echo "$am_py_prefix" | sed 's|.|.|g'`
- am_cv_python_pythondir=`echo "$am_cv_python_pythondir" | sed
"s,^$am__strip_prefix,$PYTHON_PREFIX,"`
+ am_cv_python_pythondir=`echo "$am_cv_python_pythondir" | sed
"s,^$am__strip_prefix,\\${PYTHON_PREFIX},"`
;;
*)
case $am_py_prefix in
/usr|/System*) ;;
*)
-
am_cv_python_pythondir=$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages
+
am_cv_python_pythondir="\${PYTHON_PREFIX}/lib/python$PYTHON_VERSION/site-packages"
;;
esac
;;
However, this change leads to pkg-config .pc files containing the
variable name $PYTHON_PREFIX, not its content, which makes third
packages fail to build because $PYTHON_PREFIX cannot be resolved.
For example xcb-proto.pc, a dependency of polybar, has the line
pythondir=${pc_sysrootdir}${PYTHON_PREFIX}/lib/python3.10/site-packages
but it should be
pythondir=${pc_sysrootdir}${prefix}/lib/python3.10/site-packages
which can be achieved when reverting the double backslash like
--- a/m4/python.m4 2021-10-04 04:51:12.0 +0200
+++ b/m4/python.m4 2021-10-15 08:38:08.575081215 +0200
@@ -263,7 +263,7 @@
case $am_cv_python_pythondir in
$am_py_prefix*)
am__strip_prefix=`echo "$am_py_prefix" | sed 's|.|.|g'`
- am_cv_python_pythondir=`echo "$am_cv_python_pythondir" | sed
"s,^$am__strip_prefix,\\${PYTHON_PREFIX},"`
+ am_cv_python_pythondir=`echo "$am_cv_python_pythondir" | sed
"s,^$am__strip_prefix,${PYTHON_PREFIX},"`
;;
*)
case $am_py_prefix in
@@ -305,7 +305,7 @@
case $am_cv_python_pyexecdir in
$am_py_exec_prefix*)
am__strip_prefix=`echo "$am_py_exec_prefix" | sed 's|.|.|g'`
- am_cv_python_pyexecdir=`echo "$am_cv_python_pyexecdir" | sed
"s,^$am__strip_prefix,\\${PYTHON_EXEC_PREFIX},"`
+ am_cv_python_pyexecdir=`echo "$am_cv_python_pyexecdir" | sed
"s,^$am__strip_prefix,${PYTHON_EXEC_PREFIX},"`
;;
*)
case $am_py_exec_prefix in
Using --with-python-sys-prefix makes no difference.
So is the double backslash intented or by accident?
Or am I completely misunderstanding something?
Thank you!
