On 4/23/20 1:11 PM, Richard W.M. Jones wrote:
On Thu, Apr 23, 2020 at 07:08:43PM +0100, Richard W.M. Jones wrote:
> On Thu, Apr 23, 2020 at 07:04:14PM +0100, Richard W.M. Jones wrote:
>> +# probably should *not* use this in most cases, since your plugin will
>> +# may end up containing hard paths to the local nbdkit sources.
>
> "will may" -> "may" in my local copy.
Actually in hindsight perhaps this comment/warning is wrong. I was
thinking about the original nbdkit.pc which contains absolute paths to
things like plugindir and filterdir. However firstly this one doesn't
contain these paths, and in any case even if it did they would be
unlikely to end up inside a C plugin.
Yeah, the comment is too strong. If --cflags produced
-Dsomedir=/path/to/in-tree, then you indeed would want this sort of
disclaimer, but without that, all you are affecting is the ability to
link against an uninstalled build. There's a chance that your plugin
will only be runnable by the in-tree nbdkit (if it used anything that
the installed nbdkit does not provide or understand), but that's
different than stating that your plugin will have a hard path to the
uninstalled nbdkit sources.
At any rate, once you tweak that sentence, the patch looks good, and
coupled with 2/2, fixed the build for me.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org