[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pkg-config file for lzlib

From: Antonio Diaz Diaz
Subject: Re: pkg-config file for lzlib
Date: Thu, 19 Jan 2023 19:49:09 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv: Gecko/20110420 SeaMonkey/2.0.14

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:

"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."

"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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]