[pacman-dev] Bug: using --program-prefix configure option breaks makepkg
Hi Pacman team, In the last couple of days I've been trying to build pacman for use with a homebrew sdk for the Playstation portable. The idea is for it to allow sharing of libraries for the system. To make sure this version of pacman doesn't collide with the system's, I use the --program-prefix option for the configure script, which adds "psp-" in front of all binary names. Now when using the --program-prefix option, makepkg is no longer able to work. This because it has the name for the pacman executable name hardcoded it seems. I compile with the following commands: ./configure --prefix=${PSPDEV} --with-buildscript=PSPBUILD --with-root-dir=${PSPDEV}/psp --program-prefix="psp-" --disable-doc make make install For this to work, I require the following patch: https://github.com/sharkwouter/psptoolchain/blob/psp-pacman/patches/pacman-5... Is there a way to prevent me from needing this patch? Besides this patch, the pacman 5.2.1 tarball build and works fine for my purposes. P.S. I did find another small annoyance. Which is that "make install" fails if the bash completion files are already installed. Kind regards, Wouter Wijsman
On 5/4/20 10:39 AM, Wouter Wijsman wrote:
Hi Pacman team,
In the last couple of days I've been trying to build pacman for use with a homebrew sdk for the Playstation portable. The idea is for it to allow sharing of libraries for the system. To make sure this version of pacman doesn't collide with the system's, I use the --program-prefix option for the configure script, which adds "psp-" in front of all binary names.
Now when using the --program-prefix option, makepkg is no longer able to work. This because it has the name for the pacman executable name hardcoded it seems.
I've never really experimented with --program-prefix, but I expect the general way to do this would be to add those executable names as replacements to build-aux/edit-script.sh.in (meson) and scripts/Makefile.am $(edit) (autotools). Is there e.g. a variable set in the configured Makefile which describes this prefix and can be used to define a replacement? Do you know of any examples of other autotools projects which invoke internal programs via shellscripts and have handled this before? I think for meson, this would need to be explicitly added as AFAIK meson doesn't have a comparable feature anyway.
I compile with the following commands: ./configure --prefix=${PSPDEV} --with-buildscript=PSPBUILD --with-root-dir=${PSPDEV}/psp --program-prefix="psp-" --disable-doc make make install
For this to work, I require the following patch: https://github.com/sharkwouter/psptoolchain/blob/psp-pacman/patches/pacman-5...
Is there a way to prevent me from needing this patch? Besides this patch, the pacman 5.2.1 tarball build and works fine for my purposes.
P.S. I did find another small annoyance. Which is that "make install" fails if the bash completion files are already installed.
Is this because of: for completion in makepkg pacman-key; do \ $(LN_S) pacman $(DESTDIR)/$(bashcompdir)/$$completion; \ done Because if so, you can probably get it to work by defining LN_S to add the -f flag. -- Eli Schwartz Bug Wrangler and Trusted User
On Mon, 2020-05-04 at 10:54 -0400, Eli Schwartz wrote:
On 5/4/20 10:39 AM, Wouter Wijsman wrote:
Hi Pacman team,
In the last couple of days I've been trying to build pacman for use with a homebrew sdk for the Playstation portable. The idea is for it to allow sharing of libraries for the system. To make sure this version of pacman doesn't collide with the system's, I use the --program-prefix option for the configure script, which adds "psp-" in front of all binary names.
Now when using the --program-prefix option, makepkg is no longer able to work. This because it has the name for the pacman executable name hardcoded it seems.
I've never really experimented with --program-prefix, but I expect the general way to do this would be to add those executable names as replacements to build-aux/edit-script.sh.in (meson) and scripts/Makefile.am $(edit) (autotools). Is there e.g. a variable set in the configured Makefile which describes this prefix and can be used to define a replacement?
Do you know of any examples of other autotools projects which invoke internal programs via shellscripts and have handled this before?
I think for meson, this would need to be explicitly added as AFAIK meson doesn't have a comparable feature anyway.
Thanks for the info! I did manage to fix it for autotools in the way gcc does it, for which I've submitted a patch now, but I think you're right about Meson. I don't really know much about Meson, though. Are you guys planning on keeping autotools supported or is Meson the future?
I compile with the following commands: ./configure -- prefix=${PSPDEV} --with-buildscript=PSPBUILD --with-root-dir=${PSPDEV}/psp --program-prefix="psp-" --disable-doc make make install
For this to work, I require the following patch: https://github.com/sharkwouter/psptoolchain/blob/psp-pacman/patches/pacman-5...
Is there a way to prevent me from needing this patch? Besides this patch, the pacman 5.2.1 tarball build and works fine for my purposes.
P.S. I did find another small annoyance. Which is that "make install" fails if the bash completion files are already installed.
Is this because of:
for completion in makepkg pacman-key; do \ $(LN_S) pacman $(DESTDIR)/$(bashcompdir)/$$completion; \ done
Because if so, you can probably get it to work by defining LN_S to add the -f flag.
It seems this can be set in libtool.m4, but that's generated/added by autoreconf it seems, so I don't know if that would work. I'll probably add a workaround to my build script :/
On 5/4/20 5:12 PM, wwijsman@live.nl wrote:
Thanks for the info! I did manage to fix it for autotools in the way gcc does it, for which I've submitted a patch now, but I think you're right about Meson. I don't really know much about Meson, though. Are you guys planning on keeping autotools supported or is Meson the future?
In the long term, we'd like to declare meson feature-compatible and drop autotools. There is some information here: https://bugs.archlinux.org/task/64394 I don't know that meson would be adding such a feature, and this was never explicitly supported (rather, added for free by autotools), so I'm not sure whether to tell you to do manual moving around or whether to add an option for it and manually define executable names during configure time.
I compile with the following commands: ./configure -- prefix=${PSPDEV} --with-buildscript=PSPBUILD --with-root-dir=${PSPDEV}/psp --program-prefix="psp-" --disable-doc make make install
For this to work, I require the following patch: https://github.com/sharkwouter/psptoolchain/blob/psp-pacman/patches/pacman-5...
Is there a way to prevent me from needing this patch? Besides this patch, the pacman 5.2.1 tarball build and works fine for my purposes.
P.S. I did find another small annoyance. Which is that "make install" fails if the bash completion files are already installed.
Is this because of:
for completion in makepkg pacman-key; do \ $(LN_S) pacman $(DESTDIR)/$(bashcompdir)/$$completion; \ done
Because if so, you can probably get it to work by defining LN_S to add the -f flag.
It seems this can be set in libtool.m4, but that's generated/added by autoreconf it seems, so I don't know if that would work. I'll probably add a workaround to my build script :/
If it works and covers your use case, then we can simply do this: $(LN_S) -f pacman $(DESTDIR)/$(bashcompdir)/$$completion -- Eli Schwartz Bug Wrangler and Trusted User
On 5/5/20 8:22 am, Eli Schwartz wrote:
On 5/4/20 5:12 PM, wwijsman@live.nl wrote:
Thanks for the info! I did manage to fix it for autotools in the way gcc does it, for which I've submitted a patch now, but I think you're right about Meson. I don't really know much about Meson, though. Are you guys planning on keeping autotools supported or is Meson the future?
In the long term, we'd like to declare meson feature-compatible and drop autotools. There is some information here: https://bugs.archlinux.org/task/64394
I intend on removing autotools very, very soon. So patches to fix autotools issues will not be committed (unless they are worthy of backporting to the release branch). A
participants (4)
-
Allan McRae
-
Eli Schwartz
-
Wouter Wijsman
-
wwijsman＠live.nl