Re: pkg-config file for lzlib

[Antonio Diaz Diaz]

Hello Niclas,

Niclas Rosenvik wrote:
> I like to be able to look up lzlib via pkg-config, I searched the mailing
> list and found that others want it too.

Maybe pkg-config is useful for libraries with non-standard dependencies, but 
AFAICT pkg-config is 100% useless for lzlib. You may have noticed in my 
previous answers that I don't like the idea of pkg-config and that I am 
still waiting for someone to show me a real compilation problem solved by 
the use of pkg-config:

http://lists.nongnu.org/archive/html/lzip-bug/2019-04/msg00015.html
"If I have understood correctly how pkg-config works[1], the .pc file must 
be generated by the makefile at build time, and it contains fixed directory 
names that prevent the library to be found if it is moved after instalation."

http://lists.nongnu.org/archive/html/lzip-bug/2022-06/msg00013.html
"Before even start thinking about this I need an example of a failed build 
that is fixed by the inclusion of such a pc.in file (without requiring any 
kind of autotools support)."

> So here are patches that make this work.

Thank you. Nice patch. It certainly "makes this work" in the sense that it 
creates a .pc file that can be used by pkg-config. But I still do not see 
that it solves any real problem.

For example, your patch stores the .pc file in 
"pkgconfigdir='$(libdir)/pkgconfig'", which makes me wonder why pkg-config 
can find the .pc file but can't find the library just one directory above it 
(in libdir).

Storing a database of .pc files recording the locations of libraries adds 
some problems, like finding the database itself, deciding what to do if 
there is more than one database (in /usr/lib/pkgconfig and 
/usr/local/lib/pkgconfig for example), or dealing with stale location data 
(library moved or reinstalled elsewhere).

I have several versions of lzlib installed on my machine (in different 
directories) to test plzip and tarlz, and I can't see how a .pc file could 
help me find the one I want to use each time. Having to type
  ./configure lzlib_CFLAGS='-I <includedir>' lzlib_LIBS='-L <libdir> -llz'
instead of
  ./configure CPPFLAGS='-I <includedir>' LDFLAGS='-L <libdir>'
is not an improvement. (In fact it is wrong, because <includedir> belongs in 
CPPFLAGS, not in CFLAGS).

BTW, lzlib provides macros and functions to check the version of the library 
both at compile time and run time which are more reliable than the 
configuration time test possible with pkg-config. (An application may be 
dynamically linked at run time with a different version of lzlib than the 
one it was compiled for, and this should not break the application as long 
as the library used provides the functionality required by the application).

> The install-pc target is not run by default, I leave it up to Antonio to
> decide if the pkg-config file should be installed automatically or if
> install-pc has to be run separately.

Installing the .pc file separately would be a bad idea because if one 
forgets to do it the second time, the old .pc file may become out of sync 
with the new installed library.

I think that adding a .pc file to lzlib would not solve any problems and may 
create problems where there are currently none. If lzlib is installed in a 
standard location, the compiler and the linker will find it. If lzlib is 
installed in a non-standard location (or moved after installation), 
pkg-config won't find it.

Moreover, there are discrepancies[1] among pkg-config implementations. Which 
makes me think that the concept itself of how pkg-config should work is not 
(yet?) fully resolved. Maybe it is better to provide .pc files only for 
those libraries that can take advantage of the services (?) provided by 
pkg-config.

In fact, after reading in the link below that "Current release versions of 
pkg-config, on the other hand, build a database of all known pkg-config 
files on the system before attempting to resolve dependencies", I'm moving 
all the .pc files where pkg-config won't find them. I find it unacceptably 
wasteful to read hundreds of files just to find out that you didn't need to 
read them in the first place.

[1] See section "compatibility with pkg-config" at 
http://github.com/pkgconf/pkgconf#readme

Best regards,
Antonio.