Re: [bug-libunistring] pkg-config

[Bruno Haible]

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.

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.

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

In other words, pkg-config is only acceptable for classical Linux distros
(which always install with --prefix=/usr); this is the only case in which
its problems are not visible.

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

Bruno