On Mon, Feb 16, 2015 at 14:26:56 +0000, Daniel P. Berrange wrote:
On Mon, Feb 16, 2015 at 03:11:29PM +0100, Jiri Denemark wrote:
Not all file we want to find using virFileFindResource{,Full} are generated when libvirt is built, some of them (such as RNG schemas) are distributed with sources. The current API was not able to find source files if libvirt was built in VPATH.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> --- src/Makefile.am | 2 ++ src/driver.c | 1 + src/locking/lock_driver_lockd.c | 1 + src/locking/lock_manager.c | 1 + src/remote/remote_driver.c | 1 + src/util/virfile.c | 39 ++++++++++++++++++++++++++++++--------- src/util/virfile.h | 8 +++++++- 7 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am index b41c6d4..a938d7e 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -20,6 +20,7 @@ abs_builddir = $(shell pwd) abs_topbuilddir = $(shell cd .. && pwd) abs_srcdir = $(shell cd $(srcdir) && pwd) +abs_topsrcdir = $(shell cd $(srcdir)/.. && pwd)
# No libraries with the exception of LIBXML should be listed # here. List them against the individual XXX_la_CFLAGS targets @@ -32,6 +33,7 @@ INCLUDES = -I../gnulib/lib \ -I$(srcdir)/util \ -DIN_LIBVIRT \ -Dabs_topbuilddir="\"$(abs_topbuilddir)\"" \ + -Dabs_topsrcdir="\"$(abs_topsrcdir)\"" \ $(GETTEXT_CPPFLAGS)
AM_CFLAGS = $(LIBXML_CFLAGS) \ diff --git a/src/driver.c b/src/driver.c index 1be32ef..1271597 100644 --- a/src/driver.c +++ b/src/driver.c @@ -57,6 +57,7 @@ virDriverLoadModule(const char *name) "libvirt_driver_", ".so", "src/.libs", + VIR_FILE_FIND_RESOURCE_VPATH_BUILD,
Instead of adding yet another parameter, why don't we just change the calling convention of virFileFindResource so that instead of assuming abs_topbuilddir we just make the caller prepend the builddir.
eg instead of pasing 'src/.libs' we pass
abs_topbuilddir "/src/.libs"
letting the compiler concatenate these. The enum you define is basically doing exactly that but with an extra level of indirection which doesn't seem to buy us anything
Yeah, I guess, that would work too, although it will either need one more allocation or making all calls to the non-Full variant of this API more complex. But we can live with it since virFileFind* APIs are used at about 11 places... Jirka