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