[libvirt] [PATCH] src: Generate virkeymaps.h into the correct directory

So after a9fe620372144db we are generating virkeymaps.h all the time during build. This is good. However, when doing a VPATH build, we are not generating it into the correct directory, since there's $(srcdir) prefix missing to the path to the file: make[2]: Entering directory `/home/jenkins/libvirt/systems/libvirt-fedora-20/build/src' GEN util/virkeymaps.h ... CC util/libvirt_util_la-virkeycode.lo CC util/libvirt_util_la-virkeyfile.lo CC util/libvirt_util_la-virlockspace.lo CC util/libvirt_util_la-virlog.lo ../../src/util/virkeycode.c:27:24: fatal error: virkeymaps.h: No such file or directory #include "virkeymaps.h" ^ compilation terminated. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- Even though this would qualify as build breaker, I'm sending it for review. src/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index e4660eb..0bf28cf 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -177,10 +177,10 @@ EXTRA_DIST += $(srcdir)/util/keymaps.csv $(srcdir)/util/virkeycode-mapgen.py BUILT_SOURCES += util/virkeymaps.h MAINTAINERCLEANFILES += util/virkeymaps.h -util/virkeymaps.h: $(srcdir)/util/keymaps.csv \ +$(srcdir)/util/virkeymaps.h: $(srcdir)/util/keymaps.csv \ $(srcdir)/util/virkeycode-mapgen.py $(AM_V_GEN)$(PYTHON) $(srcdir)/util/virkeycode-mapgen.py \ - <$(srcdir)/util/keymaps.csv >util/virkeymaps.h + <$(srcdir)/util/keymaps.csv >$(srcdir)/util/virkeymaps.h # Internal generic driver infrastructure NODE_INFO_SOURCES = nodeinfo.h nodeinfo.c nodeinfopriv.h -- 2.4.9

On Thu, Oct 08, 2015 at 08:35:29AM +0200, Michal Privoznik wrote:
So after a9fe620372144db we are generating virkeymaps.h all the time during build. This is good. However, when doing a VPATH build, we are not generating it into the correct directory, since there's $(srcdir) prefix missing to the path to the file:
make[2]: Entering directory `/home/jenkins/libvirt/systems/libvirt-fedora-20/build/src' GEN util/virkeymaps.h ... CC util/libvirt_util_la-virkeycode.lo CC util/libvirt_util_la-virkeyfile.lo CC util/libvirt_util_la-virlockspace.lo CC util/libvirt_util_la-virlog.lo ../../src/util/virkeycode.c:27:24: fatal error: virkeymaps.h: No such file or directory #include "virkeymaps.h" ^ compilation terminated.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> ---
Even though this would qualify as build breaker, I'm sending it for review.
src/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am index e4660eb..0bf28cf 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -177,10 +177,10 @@ EXTRA_DIST += $(srcdir)/util/keymaps.csv $(srcdir)/util/virkeycode-mapgen.py BUILT_SOURCES += util/virkeymaps.h MAINTAINERCLEANFILES += util/virkeymaps.h
-util/virkeymaps.h: $(srcdir)/util/keymaps.csv \ +$(srcdir)/util/virkeymaps.h: $(srcdir)/util/keymaps.csv \ $(srcdir)/util/virkeycode-mapgen.py $(AM_V_GEN)$(PYTHON) $(srcdir)/util/virkeycode-mapgen.py \ - <$(srcdir)/util/keymaps.csv >util/virkeymaps.h + <$(srcdir)/util/keymaps.csv >$(srcdir)/util/virkeymaps.h
If we're doing a VPATH build, surely we want to have the generated file go into $(builddir) not $(srcdir) ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On Thu, 2015-10-08 at 09:49 +0100, Daniel P. Berrange wrote:
-util/virkeymaps.h: $(srcdir)/util/keymaps.csv \ +$(srcdir)/util/virkeymaps.h: $(srcdir)/util/keymaps.csv \ $(srcdir)/util/virkeycode-mapgen.py $(AM_V_GEN)$(PYTHON) $(srcdir)/util/virkeycode-mapgen.py \ - <$(srcdir)/util/keymaps.csv >util/virkeymaps.h + <$(srcdir)/util/keymaps.csv >$(srcdir)/util/virkeymaps.h
If we're doing a VPATH build, surely we want to have the generated file go into $(builddir) not $(srcdir) ?
Definitely. I've just sent a patch that tries to fix the same issue with a different approach, please check it out. Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team
participants (3)
-
Andrea Bolognani
-
Daniel P. Berrange
-
Michal Privoznik