On Mon, Feb 12, 2018 at 4:59 PM, Bruno Haible <br...@clisp.org> wrote:
> Hi Daiki,
>> I remember there was a discussion about pkg-config support a few years
>> ago.  At that time I opposed to do that, because a similar library
>> detection mechanism is also provided by libunistring.m4.
>> However, given the wider adoption of this library (even in non-autotools
>> projects), I reconsider adding it.
>> What do people think?
> I still consider it an extremely bad idea. EACH time I had to deal with
> packages that require pkg-config in the past year, it reinforced my
> conviction how broken it is.
> The points that pkg-config gets wrong are:
>   1) It cannot support multiple compilers (e.g. building a library with
>      GCC and using it with SunPRO C on Solaris).
>   2) Users who install packages with --prefix need to manually set up
>      PKG_CONFIG_PATH environment variable (additionally to PATH and
>      --prefix).
>> The change itself would be trivial as attached.

I think it is reasonable to expect that pkg-config will not cover
every use case possible, however it has its benefits on very common
uses. The advantages that I see in libraries that use pkg-config:
 1. The installed library can be determined by users on cmd in a cross
platform way (i.e., using rpm in fedora/centos and dpkg in
debian/ubuntu), as pkg-config --modver gnutls.
 2. It makes it very easy to introduce conditional to version
dependencies on configure scripts. If for example my code only works
with cmocka 1.0.1 or later, I use:
 PKG_CHECK_MODULES(CMOCKA, [cmocka >= 1.0.1], [with_cmocka=yes],
The alternative, is writing programs in configure to check for
specific functionality introduced in that version, or check for the
absence of bugs, version numbers in headers, etc., depending on the
 3. It provides a consistent method to override the system library.
E.g, on the example with cmocka above, as user I can run
'CMOCKA_LIBS="-L/usr/local/lib -lcmocka2" ./configure' to override the
default library shipped in the system.

Overall, it may be a matter of taste. No-one is forced to use
pkg-config, if they see no benefit. It would be great to have it for
ones who see benefit in it, if it is not a big maintenance burden.

> Thanks, your patch highlights two more reasons why pkg-config is broken:
>   3) When a user uses --prefix to install a library, the user who uses
>      the library needs -Wl,-rpath,${LIBDIR} when linking - otherwise
>      executables don't run.
>      You perfectly highlighted this by omitting such an option from the
>      'Libs' line.

I do not see as an issue in pkg-config as the same result happens if
not use. The 'rpath' in my opinion is something optional, and should
not be forced upon by software (I may for example compile to run in a
chroot environment, container etc.).

>   4) It cannot distinguish whether libtool is used to perform the linking
>      or not. With libtool, one needs -R ${LIBDIR}. Without libtool,
>      one needs -Wl,-rpath,${LIBDIR}.
>      You perfectly highlighted this by choosing one of @LIBICONV@
>      @LTLIBICONV@ in Libs.private. (The other choice would have been
>      equally wrong.)

My understanding is that, pkg-config is not supposed to contain
libtool specific flags. It is expected to be used by any project
whether compiled by libtool or not.

> For completeness: Earlier, there was also a problem between pkg-config and
> cross-compilation. I don't know whether this problem still exists.

I'm relying on it for cross compilation on windows, and I'm not aware
of any issues.


Reply via email to