Libguestfs - Apr 2020 - Re: [PATCH nbdkit 1/2] server: Add pkg-config file to compile against locally compiled nbdkit.

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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

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