Re: Discussion about pkg-config on the autoconf list

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Sat, 24 Oct 2009 10:32:37 +1100

On Saturday 24 October 2009 03:58:17 Murray S. Kucherawy wrote:
> Looks like there's mostly negative views of the idea of using pkg-config
> with autoconf at least over there:
>
> The root of the thread, if you're interested:
> http://lists.gnu.org/archive/html/autoconf/2009-10/msg00132.html
>

So breaking it out:

1. can't run autoconf without pkg-confg installed
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00133.html

not true in the way I understood this. aclocal installs the PKG_* macros in
aclocal.m4. If you run aclocal on a machine without the PKG_* m4 original
files on I'm not sure what happens.

summary - may affect some users that what to rebuild the autoconf of this
package on non- pkg-config installed systems.

2.
pkg-config tests for indirectly what versions are available installed of a
particular library rather than testing features of the library. This can be a
good thing.
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00137.html
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00146.html
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00146.html

generally considered a good thing. If we need to check features we do what we
did with openssl - let pkg-config find the library and then AC_CHECK_* the
librarys/includes more carefully

3.
run into flag conflicts... resolved by lettings user specify file locations
with *FLAGS
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00136.html

well pkg-config lets users set {NAME}_CFLAGS {NAME}_LDFLAGS in the same way
for the same purpose.

4.
users compiling their own library means pkg-config picks up their library
rather than the system. This would only occur if a) the user forced the pkg-
config to install into the system location or b) set PKG_CONFIG_PATH manually.
This is very useful in a number of scenarios.
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00139.html
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00140.html
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00141.html

As a) is caused by someone either knowledgable or silly I don't think we need
to worry here.
b) is actually how I tested the libopendkim development without clobbering
system files and gives users flexibility of version selection a level before
resorting to {NAME}*FLAGS settings

5.
pkg-config makes the installed libraries pollute the CFLAGS
rather than the system
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00139.html

This is quite true. Library CFLAGS are populated to the opendkim build. The
ones that are populated will be the openssl/tre libs. By default these don't
polute too much. Distro maintainers sometimes make sure these are fairly
clean. If the user compiles them then they get a bit more confusion if they
compile openssl for example with CFLAGS that they don't want in opendkim.

6.
old system troubles (~3 years) unquantified
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00139.html
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00140.html

if this was quantified I could answer this better. I'm guessing the solutions
in #3 would help.

7.
pkg-config can't find libraries because package maintainer didn't install
them.
http://lists.gnu.org/archive/html/autoconf/2009-10/msg00140.html

Solved by #3. the libraries we use have been using pkg-config properly for
quite a while.
Received on Fri Oct 23 2009 - 23:33:10 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:32:29 PST