One of the good things about using pkg-config in a software package is that its configuration script can easily specify external dependencies by their name and their version. It doesn't need to mess with other requirements, such as specific build flags or tricks to determine whether the installed library is new enough to fulfill its needs.
In other words: a program can focus on detecting its direct dependencies rather than having to look for other underlying libraries it doesn't care about. And most important: the user can easily see which these are.
Consider the following example: your program needs, at least, GTK+ 2.6.4, but it doesn't want to use any specific Pango functionality. In this case, the program depends on a specific version of GTK+ (2.6.4), but Pango's version is irrelevant. In fact, as the program doesn't deal with Pango at all, Pango could be replaced by a similar component in a future version of GTK+ and your program could remain functional. (Hey, this is just an example! I'm by no means suggesting that Pango should be replaced ;-)
In the previous example, our imaginary software package could do something like:
PKG_CHECK_MODULES(gtk2+ >= 2.6.0)
The occasional reader can later see which are the required and direct dependencies of the program by looking at the output of the configure script (or directly at the source script and searching for calls to this macro).
However, if our previous program required to use Pango, say version 1.8.0, it could do the following:
PKG_CHECK_MODULES(pango >= 1.8.0 gtk2+ >= 2.6.0)
Which clearly states that both Pango and GTK+ are required.
Why is this useful? It makes things extremely easy to the package maintainer who has to analyze the dependencies of a given software program and define the correct dependencies for his package.
