From: newbluemoon <newbluemoon@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: Issue with automake 1.16.4+ and python
Date: Sun, 17 Oct 2021 07:57:10 +0200 [thread overview]
Message-ID: <20211017055710.Yo6Y9N5BgUWhthImxVTk0I5TmVOfmTB9v3jFXC81sBM@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-33559@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]
New comment by newbluemoon on void-packages repository
https://github.com/void-linux/void-packages/issues/33559#issuecomment-945054931
Comment:
So I got a response :)
> 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
It seems automake is doing the right thing and xcb-proto should create its .pc file differently.
However, I guess this behaviour is hidden in other projects using autotools, too, and will be revealed one after another when they start using automake >=1.16.4.
Maybe a post-install hook could check for `$PYTHON_PREFIX` and print a warning or error out?
next prev parent reply other threads:[~2021-10-17 5:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-15 8:36 [ISSUE] " newbluemoon
2021-10-16 19:00 ` ahesford
2021-10-16 19:21 ` newbluemoon
2021-10-16 19:25 ` ahesford
2021-10-16 19:41 ` newbluemoon
2021-10-16 19:48 ` newbluemoon
2021-10-17 5:57 ` newbluemoon [this message]
2021-10-17 7:00 ` newbluemoon
2021-10-17 13:02 ` ahesford
2021-10-17 14:48 ` newbluemoon
2022-06-08 2:12 ` github-actions
2022-06-22 2:13 ` [ISSUE] [CLOSED] " github-actions
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211017055710.Yo6Y9N5BgUWhthImxVTk0I5TmVOfmTB9v3jFXC81sBM@z \
--to=newbluemoon@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).