cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCH] add support for pkg-config detection of libidn (Daniel)?

From: Yang Tse <>
Date: Fri, 2 Dec 2011 19:33:42 +0100

Forwarding message to given that I forgot to
hit 'reply to all'.

---------- Forwarded message ----------
From: Yang Tse <>
Date: 2011/12/2
Subject: Re: [PATCH] add support for pkg-config detection of libidn (Daniel)?
To: Daniel Stenberg <>

2011/12/2 Daniel Stenberg wrote:

> I think it sounds like a good idea, assuming we can use that to clean up our
> pkg-config uses in and related files.

There are lots of threads on the autoconf mailing list in which
autoconf maintainers (and others) describe pkg-config problems. I'm
not going to repeat them here.

I'll try to keep this to the minumum number of reasons for which we
should not include pkg.m4 in our tree nor use any m4 macro provided
with that file. This does not mean that I could not mention other
reasons it is simply that I don't feel the need to elaborate any
further nor the need to trash someone's else work.

> We already use other m4 packages (from libtool for example) that are GPL
> with that exception language in their headers, so I can't see any problems
> with us adding another file in the same spirit.

Yep. No problem with the license.


If pkg.m4 PKG_CHECK_MODULES is used, no matter if pkg.m4 is in our
source tree or pulled from default locations such as
/usr/share/aclocal then pkg-config becomes a configure-time
requirement unless we code its usage in a similar way to what we
already have. IOW we have to keep existing logic and even add more in
order to allow usage of PKG_CHECK_MODULES without making pkg-config a

Additionally PKG_CHECK_MODULES already falls short for our needs. It
does not provide the ability to specify for each library the supposed
location of .pc file (we would need to reimplement the logic we
already have that allows this). It only provides CFLAGS and LIBS as a
whole while our existing logic already uses a finer grained method
because we need it further on our build infrastructure.

If we imported pkg.m4 into our tree and modified it for our needs it
would no longer be PKG_CHECK_MODULES. So what is the point of
importing something if we can not use it ASIS.

pkg-config with all its limitations is much powerful than pkg.m4, it
is much better to use the real-thing and forget about the m4 wrapper
it currently provides.

List admin:
Received on 2011-12-02