Re: [bug-libunistring] pkg-config

[Daiki Ueno]

Nikos Mavrogiannopoulos <address@hidden> writes:

> 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],
> [with_cmocka=no])
> 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
> library.
>  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.

Thank you for the clarification.  As far as I can see, the only argument
against adding it is that we should not encourage our users to switch
over to the inferior method for linking with the library.

On the other hand, the recommended way mentioned in the manual is not
handier than pkg-config:
https://www.gnu.org/software/libunistring/manual/html_node/Autoconf-macro.html#Autoconf-macro

Perhaps, if we could improve this situation, e.g., by shipping the
autoconf macro in the distribution or by providing a traditional
*-config script that prints the precise linker configuration, it
wouldn't be a problem to add a pkg-config file as an alternative choice?

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

I agree.

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

Indeed, I actually took it from libidn2.pc, which has:

  Libs.private: @LTLIBICONV@ @LTLIBUNISTRING@

However, this would also be simplified with:

  Requires.private: libunistring

if we could assume libunistring.pc installed on the system.

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

Me neither.

Regards,
-- 
Daiki Ueno