Libguestfs - Mar 2020 - [PATCH] lib: remove extra @LIBS@ from pkg-config file

At the moment it is empty, so probably it does not exist. Remove it to
avoid adding spurious content to the pkg-config file in case that
variable will get a value in the future.
---
 lib/libguestfs.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/libguestfs.pc.in b/lib/libguestfs.pc.in
index 679ed7eba..013bf0f28 100644
--- a/lib/libguestfs.pc.in
+++ b/lib/libguestfs.pc.in
@@ -8,4 +8,4 @@ Version: @VERSION@
 Description: libguestfs library for accessing and modifying VM images
 Requires:
 Cflags:
-Libs: -lguestfs @LIBS@
+Libs: -lguestfs
-- 
2.24.1

On 3/11/20 7:21 AM, Pino Toscano wrote:
> At the moment it is empty, so probably it does not exist. Remove it to
> avoid adding spurious content to the pkg-config file in case that
> variable will get a value in the future.
> ---
>   lib/libguestfs.pc.in | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/libguestfs.pc.in b/lib/libguestfs.pc.in
> index 679ed7eba..013bf0f28 100644
> --- a/lib/libguestfs.pc.in
> +++ b/lib/libguestfs.pc.in
> @@ -8,4 +8,4 @@ Version: @VERSION@
>   Description: libguestfs library for accessing and modifying VM images
>   Requires:
>   Cflags:
> -Libs: -lguestfs @LIBS@
> +Libs: -lguestfs
If I recall, @LIBS@ is the user-controlled variable for adding 
dependencies on a user-specified library beyond what configure would 
normally find.  You're right that it is usually empty, but if a user 
runs './configure LIBS=...' to pick up something special, then that 
something special had better still be present through uses of the 
resulting library.  Thus, I'm inclined to think we don't want this
patch.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

On Wednesday, 11 March 2020 13:32:41 CET Eric Blake
wrote:
> On 3/11/20 7:21 AM, Pino Toscano wrote:
> > At the moment it is empty, so probably it does not exist. Remove it to
> > avoid adding spurious content to the pkg-config file in case that
> > variable will get a value in the future.
> > ---
> >   lib/libguestfs.pc.in | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/libguestfs.pc.in b/lib/libguestfs.pc.in
> > index 679ed7eba..013bf0f28 100644
> > --- a/lib/libguestfs.pc.in
> > +++ b/lib/libguestfs.pc.in
> > @@ -8,4 +8,4 @@ Version: @VERSION@
> >   Description: libguestfs library for accessing and modifying VM
images
> >   Requires:
> >   Cflags:
> > -Libs: -lguestfs @LIBS@
> > +Libs: -lguestfs
> 
> If I recall, @LIBS@ is the user-controlled variable for adding 
> dependencies on a user-specified library beyond what configure would 
> normally find.  You're right that it is usually empty, but if a user 
> runs './configure LIBS=...' to pick up something special, then that
> something special had better still be present through uses of the 
> resulting library.
That is fine IMHO. The problem is that libguestfs.pc represents the
public interface of libguestfs: any application using libguestfs via
the information in the pkg-config file will most likely honour them.
If I need libguestfs to link to a custom library, it will most
certainly be only needed for the internal implementation, just like all
the libraries currently used are (PCRE, libvirt, libxml2, libselinux,
jansson, FUSE).

-- 
Pino Toscano

On Wed, Mar 11, 2020 at 01:21:06PM +0100, Pino Toscano
wrote:
> At the moment it is empty, so probably it does not exist. Remove it to
> avoid adding spurious content to the pkg-config file in case that
> variable will get a value in the future.
> ---
>  lib/libguestfs.pc.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/libguestfs.pc.in b/lib/libguestfs.pc.in
> index 679ed7eba..013bf0f28 100644
> --- a/lib/libguestfs.pc.in
> +++ b/lib/libguestfs.pc.in
> @@ -8,4 +8,4 @@ Version: @VERSION@
>  Description: libguestfs library for accessing and modifying VM images
>  Requires:
>  Cflags:
> -Libs: -lguestfs @LIBS@
> +Libs: -lguestfs
I don't really know about this any better than Eric, but I did look at
the about 250 *.pc.in files in random development trees in my home
directory.  Not a statistically independent sample!

Only these (discounting libguestfs) have @LIBS@ in the file:

 - augeas
 - hivex
 - libarchive
 - libnbd
 - libpng
 - libxml2 (twice)
 - openvswitch (4 sub-libraries)
 - portaudio

Hivex and libnbd are likely derived from libguestfs, and maybe augeas.
Note that libvirt doesn't appear.

I think we can make an argument that it's a rarely used feature and we
should remove it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

On 3/11/20 4:17 PM, Richard W.M. Jones wrote:
> On Wed, Mar 11, 2020 at 01:21:06PM +0100, Pino Toscano wrote:
>> At the moment it is empty, so probably it does not exist. Remove it to
>> avoid adding spurious content to the pkg-config file in case that
>> variable will get a value in the future.
>> ---
>>   lib/libguestfs.pc.in | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/libguestfs.pc.in b/lib/libguestfs.pc.in
>> index 679ed7eba..013bf0f28 100644
>> --- a/lib/libguestfs.pc.in
>> +++ b/lib/libguestfs.pc.in
>> @@ -8,4 +8,4 @@ Version: @VERSION@
>>   Description: libguestfs library for accessing and modifying VM images
>>   Requires:
>>   Cflags:
>> -Libs: -lguestfs @LIBS@
>> +Libs: -lguestfs
> 
> I don't really know about this any better than Eric, but I did look at
> the about 250 *.pc.in files in random development trees in my home
> directory.  Not a statistically independent sample!
> 
> Only these (discounting libguestfs) have @LIBS@ in the file:
> 
>   - augeas
>   - hivex
>   - libarchive
>   - libnbd
>   - libpng
>   - libxml2 (twice)
>   - openvswitch (4 sub-libraries)
>   - portaudio
> 
> Hivex and libnbd are likely derived from libguestfs, and maybe augeas.
> Note that libvirt doesn't appear.
> 
> I think we can make an argument that it's a rarely used feature and we
> should remove it.
Okay, I'm also in favor of removing it.  After thinking about it, Pino's
reminder that the .pc is what other code should use to link to us, 
rather than what we had to link to internally, makes sense - even if a 
user passes LIBS= during configure, that should not leak to the outside 
use of our public interface.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org