GNU bug report logs - #51225
Possible bug in python.m4, automake 1.16.4+

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51225 in the body.
You can then email your comments to 51225 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: bluemoon <blaumolch <at> mailbox.org>
To: bug-automake <at> gnu.org
Subject: Possible bug in python.m4, automake 1.16.4+
Date: Fri, 15 Oct 2021 09:58:26 +0200

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.000000000 +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!

Message #8 received at 51225 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: blaumolch <at> mailbox.org
Cc: jmr <at> macports.org, 51225 <at> debbugs.gnu.org
Subject: Re: bug#51225: Possible bug in python.m4, automake 1.16.4+
Date: Sat, 16 Oct 2021 19:32:19 -0600

    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.

Message #11 received at 51225 <at> debbugs.gnu.org (full text, mbox):

From: Joshua Root <jmr <at> macports.org>
To: Karl Berry <karl <at> freefriends.org>, blaumolch <at> mailbox.org
Cc: 51225 <at> debbugs.gnu.org
Subject: Re: bug#51225: Possible bug in python.m4, automake 1.16.4+
Date: Sun, 17 Oct 2021 13:30:59 +1100

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

Message #14 received at 51225 <at> debbugs.gnu.org (full text, mbox):

From: bluemoon <blaumolch <at> mailbox.org>
To: Joshua Root <jmr <at> macports.org>, Karl Berry <karl <at> freefriends.org>
Cc: 51225 <at> debbugs.gnu.org
Subject: Re: bug#51225: Possible bug in python.m4, automake 1.16.4+
Date: Sun, 17 Oct 2021 07:46:20 +0200

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.

Message #17 received at 51225 <at> debbugs.gnu.org (full text, mbox):

From: bluemoon <blaumolch <at> mailbox.org>
To: Joshua Root <jmr <at> macports.org>, Karl Berry <karl <at> freefriends.org>
Cc: 51225 <at> debbugs.gnu.org
Subject: Re: bug#51225: Possible bug in python.m4, automake 1.16.4+
Date: Sun, 17 Oct 2021 08:54:33 +0200

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! :)

Message #22 received at 51225-done <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 51225-done <at> debbugs.gnu.org
Subject: Re: bug#51225: Possible bug in python.m4, automake 1.16.4+
Date: Sun, 17 Oct 2021 15:20:49 -0600

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.