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(a)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