On Mon, Mar 10, 2014 at 12:31:00 -0600, Eric Blake wrote:
> On 03/10/2014 09:26 AM, Jiri Denemark wrote:
> > When libvirtd is run from a build directory without being installed, it
> > should not depend on files from a libvirt package installed in the
> > system. Not only because there may not be any libvirt installed at all.
> > We already do a good job for plugins but cpu_map.xml was still loaded
> > from the system.
> >
> > The Makefile.am change is necessary to make this all work from VPATH
> > builds since libvirtd has no idea where to find libvirt sources. It only
> > knows the path from which it was started, i.e, a builddir.
> >
>
> > +++ b/src/Makefile.am
> > @@ -977,6 +977,10 @@ libvirt_la_BUILT_LIBADD += libvirt_cpu.la
> > libvirt_cpu_la_CFLAGS = \
> > -I$(top_srcdir)/src/conf $(AM_CFLAGS)
> > libvirt_cpu_la_SOURCES = $(CPU_SOURCES)
> > +libvirt_cpu_la_DEPENDENCIES = $(abs_builddir)/cpu/cpu_map.xml
> > +
> > +$(abs_builddir)/cpu/cpu_map.xml:
> > + $(AM_V_GEN)ln -s $(srcdir)/cpu/cpu_map.xml $@
>
> Does this really work in both VPATH (create the link) and in-tree builds
> (you would be linking a file to itself, but then again the file is
> already up-to-date so the ln doesn't get run)? Does it pass 'make
> distcheck'? It looks a bit odd to me, but if it works, I'm okay ACKing it.
It works in in-tree builds as well as VPATH builds as long as VPATH is
not relative. Thanks for suggesting make distcheck, which revealed this
bug. The link command needs to be changed to
$(AM_V_GEN)ln -s $(abs_srcdir)/cpu/cpu_map.xml $@
so that it also works in relative VPATH build.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list