[libvirt] [PATCH] Load CPU map from builddir when run uninstalled

Jiri Denemark jdenemar at redhat.com
Wed Mar 12 15:47:18 UTC 2014


On Tue, Mar 11, 2014 at 11:05:34 +0100, Jiri Denemark wrote:
> 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.

I pushed the patch with this small change squashed in after checking
with Eric this satisfies the "if it works, I'm okay ACKing it"
condition.

Jirka




More information about the libvir-list mailing list