[Qemu-devel] [PATCH] Makefile: Drop $(DESTDIR) from generated FW paths

[Qemu-devel] [PATCH] Makefile: Drop $(DESTDIR) from generated FW paths

[Michal Privoznik]

The way that generating firmware descriptor files work is that
for every input file, every occurrence of @DATADIR@ within the
file is replaced with $(DESTDIR)$(qemu_datadir). This works as
long as DESTDIR is empty. But in some cases (e.g. on my Gentoo
box), compilation is done in one dir, then the installation is
done to another dir and then package manager copies over the
installed files. It's obvious that $(DESTDIR) must be ignored
otherwise the generated FW descriptor files will refer to old
installation directory and ignore --prefix given to ./configure.

Steps to reproduce:
1) qemu.git $ mkdir _build _install; cd _build && \
   ../configure --prefix=/usr && make && \
   make DESTDIR=../_install install

2) Observe wrong path:
   qemu.git/_build $ grep filename ../_install/usr/share/qemu/firmware/*

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index cfab1561b9..85862fb81a 100644
--- a/Makefile
+++ b/Makefile
@@ -881,7 +881,7 @@ ifneq ($(DESCS),)
 	$(INSTALL_DIR) "$(DESTDIR)$(qemu_datadir)/firmware"
 	set -e; tmpf=$$(mktemp); trap 'rm -f -- "$$tmpf"' EXIT; \
 	for x in $(DESCS); do \
-		sed -e 's,@DATADIR@,$(DESTDIR)$(qemu_datadir),' \
+		sed -e 's,@DATADIR@,$(qemu_datadir),' \
 			"$(SRC_PATH)/pc-bios/descriptors/$$x" > "$$tmpf"; \
 		$(INSTALL_DATA) "$$tmpf" \
 			"$(DESTDIR)$(qemu_datadir)/firmware/$$x"; \
-- 
2.21.0

Re: [Qemu-devel] [PATCH] Makefile: Drop $(DESTDIR) from generated FW paths

[Peter Maydell]

On Mon, 5 Aug 2019 at 13:54, Michal Privoznik <mprivozn@redhat.com> wrote:
>
> The way that generating firmware descriptor files work is that
> for every input file, every occurrence of @DATADIR@ within the
> file is replaced with $(DESTDIR)$(qemu_datadir). This works as
> long as DESTDIR is empty. But in some cases (e.g. on my Gentoo
> box), compilation is done in one dir, then the installation is
> done to another dir and then package manager copies over the
> installed files. It's obvious that $(DESTDIR) must be ignored
> otherwise the generated FW descriptor files will refer to old
> installation directory and ignore --prefix given to ./configure.
>
> Steps to reproduce:
> 1) qemu.git $ mkdir _build _install; cd _build && \
>    ../configure --prefix=/usr && make && \
>    make DESTDIR=../_install install
>
> 2) Observe wrong path:
>    qemu.git/_build $ grep filename ../_install/usr/share/qemu/firmware/*
>
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index cfab1561b9..85862fb81a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -881,7 +881,7 @@ ifneq ($(DESCS),)
>         $(INSTALL_DIR) "$(DESTDIR)$(qemu_datadir)/firmware"
>         set -e; tmpf=$$(mktemp); trap 'rm -f -- "$$tmpf"' EXIT; \
>         for x in $(DESCS); do \
> -               sed -e 's,@DATADIR@,$(DESTDIR)$(qemu_datadir),' \
> +               sed -e 's,@DATADIR@,$(qemu_datadir),' \
>                         "$(SRC_PATH)/pc-bios/descriptors/$$x" > "$$tmpf"; \
>                 $(INSTALL_DATA) "$$tmpf" \
>                         "$(DESTDIR)$(qemu_datadir)/firmware/$$x"; \
> --
> 2.21.0

Hi -- this looks like a duplicate of
https://patchew.org/QEMU/20190530192812.17637-1-olaf@aepfle.de/

(which Philippe has put in a pullreq which I guess is
destined for 4.1, though I'm still waiting for confirmation
of that, ie that it really is a for-4.1-worthy bug).

thanks
-- PMM

Re: [Qemu-devel] [PATCH] Makefile: Drop $(DESTDIR) from generated FW paths

[Michal Prívozník]

On 8/5/19 3:00 PM, Peter Maydell wrote:
> <snip/>
> Hi -- this looks like a duplicate of
> https://patchew.org/QEMU/20190530192812.17637-1-olaf@aepfle.de/
> 
> (which Philippe has put in a pullreq which I guess is
> destined for 4.1, though I'm still waiting for confirmation
> of that, ie that it really is a for-4.1-worthy bug).
> 

Ah, did not realize that. Sorry. I've replied there.

Michal