PKG_CHECK_MODULES considered harmful?

Question

Various developers discourage the usage of the PKG_CHECK_MODULES (for example, in this answer) but there is no clear, comprehensive explanation of their reasons

Answer 1

There is a blog post here that goes into a bit of detail on the bad side of PKG_CHECK_MODULES:

http://tirania.org/blog/archive/2012/Oct-20.html

or this stackoverflow question:

Using the pkg-config macro PKG_CHECK_MODULES failing

It essentially boils down to: It causes very unhelpful errors if someone is trying to run autoconf and doesn't have pkg-config installed. Here's an example of an error I got today running autoconf && ./configure:

./configure: line 5283: syntax error near unexpected token `FFMPEG,'
./configure: line 5283: `   PKG_CHECK_MODULES(FFMPEG, libavutil libavformat libavcodec libswscale, HAVE_FFMPEG=yes)'

To a user/developer just trying to compile a package, this doesn't scream "you need to install pkg-config".

If (as the article suggests) you just call pkg-config directly, you get more helpful errors, e.g.:

AC_SUBST(MONO_LIBS)
AC_SUBST(MONO_CFLAGS)
if pkg-config --atleast-version=2.10 mono; then
   MONO_CFLAGS=`pkg-config --cflags mono`
   MONO_LIBS=`pkg-config --libs mono`
else
   AC_MSG_ERROR(Get your mono from www.go-mono.com)
fi

Edit: in a comment Helmut Grohne says:

Please don't call pkg-config directly. Doing so breaks cross compilation. Use AC_PATH_TOOL(PKG_CONFIG,pkg-config) or better PKG_PROG_PKG_CONFIG to discover which $PKG_CONFIG to use.

I would presume this is correct and you should follow his suggestion, but I've not personally tried it.

Other people suggest not using pkg-config at all; that's a separate issue.

Answer 2

One significant problem with PKG_CHECK_MODULES is that it causes failures where it should not. If a user installs libfoo in /p/a/t/h and invokes a configure script with LDFLAGS=-L/p/a/t/h, the user is justified in expecting the configury to find libfoo. But, the user also must set PKG_CONFIG_PATH so that the configure script can find foo.pc in order for the configury to succeed, and in my opinion that is broken. It would be possible to invoke AC_CHECK_LIB and then only invoke PKG_CHECK_MODULES if the library is not found through the standard mechanism to avoid that problem. Another issue is that it is entirely possible for PKG_CHECK_MODULES to find a .pc file in which the information is inaccurate, causing the build to fail. In that case, it is necessary to invoke AC_CHECK_LIB after PKG_CHECK_MODULES.

In short, to use PKG_CHECK_MODULES correctly, it is necessary to invoke AC_CHECK_LIBS first, then conditionally invoke PKG_CHECK_MODULES, and then invoke AC_CHECK_LIBS again to validate the information found by PKG_CHECK_MODULES. All of this additional work on the part of the maintainer just to make it easier for users to install their libraries in non-standard location is absurd. The user should set up their tool chain to find libraries through the standard mechanisms.

-- EDIT --

To clarify, I am not suggesting that a package which uses a library which encourages the use of PKG_CHECK_MODULES should avoid using it in their configury. Rather, I am recommending that libraries not encourage its use and stop distributing .pc files. The problem that is trying to be solved by .pc files is better addressed at a higher level. The autotools are not a package management system, and this is a problem that should be addressed by a package management tool.