The gnome-config script was a precursor to pkg-config, they are tools used that you can run and use to extract information about the flags needed to compile some code, link some code, or check for a version. gnome-config itself was a pluggable version of Tcl's tclConfig.sh script.
The idea is simple: pkg-config is a tiny little tool that uses a system database of packages to provide version checking and build information to developers. Said database is merely a well-known directory in the system containing files with the extension ".pc", one per file.
These scripts are designed to be used in shell scripts to probe if a particular software package has been installed, for example, the following shell script probes whether Mono is installed in the system:
# shell script
if pkg-config --exists mono; then
echo "Found Mono!"
else
echo "You can download mono from www.go.mono.com"
fi
It can also be used in simple makefiles to avoid hardcoding the paths to your software. The following makefile shows how:
CFLAGS = `pkg-config --cflags mono` LIBS = `pkg-config --libs mono` myhost: myhost.c
And if you are using Automake and Autoconf to probe for the existence of a module with a specific version and extract the flags needed to build a module, you would do it like this:
AC_SUBST(MONO_FLAGS)
AC_SUBST(MONO_LIBS)
if pkg-config --atleast-version=2.10 mono; then
MONO_FLAGS=`pkg-config --cflags mono`
MONO_LIBS=`pkg-config --libs mono`
else
AC_MSG_ERROR("You need at least Mono 2.10")
fi
There are two main use cases for pkg-config.
Probing: You use the tool to pobe for some condition about a package and taking an action based on this. For this, you use the pkg-config exit code in your scripts to determine whether the condition was met. This is what both the sample automake and the first script show.
Compile Information: You invoke the tool which outputs to standard output the results. To store the result or pass the values, you use the shell backtick (`). That is all there is to it (example: version=`pkg-config --version`).
The tool is so immensely simple that anyone can learn every command that matters in less than 5 minutes. The whole thing is beautiful because of its simplicity.
Perhaps it was a cultural phenomenon, perhaps someone that had nothing better to do, perhaps someone that was just trying to be thorough introduced one of the most poisoning memes into the pool of ideas around pkg-config.
Whoever did this, thought that the "if" statement in shell was a complex command to master or that someone might not be able to find the backtick on their keyboards.
And they hit us, and they hit us hard.
They introduced pkg.m4, a macro intended to be used with autoconf, that would allow you to replace the handful of command line flags to pkg-config with one of their macros (PKG_CHECK_MODULES, PKG_CHECK_EXISTS). To do this, they wrote a 200 line script, which replaces one line of shell code with almost a hundred. Here is a handy comparison of what these offer:
# Shell style 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 # # With the idiotic macros # PKG_CHECK_MODULES([MONO], [mono >= 2.10],[], [ AC_MSG_ERROR(Get your mono from www.go-mono.com) ]) # # If you do not need split flags, shell becomes shorter # if pkg-config --atleast-version=2.10 mono; then CFLAGS="$CFLAGS `pkg-config --cflags mono`" LIBS="$LIBS `pkg-config --libs mono`" else AC_MSG_ERROR(Get your mono from www.go-mono.com) fi
The above shows the full benefit of using a macro, MONO is a prefix that will have LIBS and CFLAGS extracted. So the shell script looses. The reality is that the macros only give you access to a subset of the functionality of pkg-config (no support for splitting -L and -l arguments, querying provider-specific variable names or performing macro expansion).
Most projects, adopted the macros because they copy/pasted the recipe from somewhere else, and thought this was the right way of doing things.
The hidden price is that saving that few lines of code actually inflicts a world of pain on your users. You will probably see this in your forums in the form of:
Subject: Compilation error I am trying to build your software, but when I run autogen.sh, I get the following error: checking whether make sets $(MAKE)... yes checking for pkg-config... /usr/bin/pkg-config ./configure: line 1758: syntax error near unexpected token FOO,' ./configure: line 1758:PKG_CHECK_MODULES(FOO, foo >= 2.9)'
And then you will engage in a discussion that in the best case scenario helps the user correctly configure his ACLOCAL_FLAGS, create his own "setup" script that will properly configure his system, and your new users will learn the difference between running a shell script and "sourcing" a shell script to properly setup his development system.
In the worst case scenario, the discussion will devolve into how stupid your user is for not knowing how to use a computer and how he should be shot in the head and taken out to the desert for his corpse to be eaten by vultures; because, god dammit, they should have googled that on their own, and they should have never in the first place have installed two separate automake installations in two prefixes, without properly updating their ACLOCAL_FLAGS or figured out on their own that their paths were wrong in the first place. Seriously, what moron in this day and age is not familiar with the limitations of aclocal and the best practices to use system-wide m4 macros?
Hours are spent on these discussions every year. Potential contributors to your project are driven away, countless hours that could have gone into fixing bugs and producing code are wasted, you users are frustrated. And you saved 4 lines of code.
The pkg.m4 is a poison that is holding us back.
We need to end this reign of terror.
Send pull requests to eliminate that turd, and ridicule anyone that suggests that there are good reasons to use it. In the war for good taste, it is ok to vilify and scourge anyone that defends pkg.m4.
Posted on 20 Oct 2012