Acceptance of pkg-config and .pc files

[C. Thomas Stover]

On Sun, 23 Feb 2014 14:57:13 +0100, Дилян Палаузов wrote:

> Hello,
> 
> the subject might be misleading, but I did not come to a better idea.
> 
> I know it is up to every distribution to distribute or not the .pc
> files, but compiling the software yourself, you have to rely on some
> mechanism to figure out the information pkg-config delivers.  If
> pkg-config is not installed on every modern system, then one has to
> maintain workarounds for finding how to link.
> 
> When does it make sense to have workarounds for missing .pc files, and
> when are these workarounds pointless, as .pc files and pkg-config are
> always provided?
> 
> Let's take an example: gnutls and opendkim.  The latter checks at
> ./configure time if gnutls' pkg-config is installed and if it cannot
> find it, then it tries other ways.  What is the chance, that
> gnutls(-devel) is installed, but gnutls.pc is not found (provided that
> ./configure insists that pkg-config must be installed)?  Do you have any
> experience, or even a link, where this information is presented?
> 
> Thanks in advance for your reply.
> 
> Kind regards
>    Dilyan Palauzov


I see two issues in your question: 

What to do when pkg-config is not installed?

	I would say the answer is to get pkg-config installed. Seriously. 
You need to get either the main line pkg-config, one of the other 
implementations, or one of the forks to work natively or in a cross tool 
chain for what ever you are doing. After all, if you have a situation 
where pkg-config is not available, you are not likely to have other 
configure style facilities as well. For example, on windows I require 
either a cross compile from *nix or cygwin for the build environment. 
Most other niche / hobby environments can be cross targeted from *nix. If 
you can't get a build environment for a target with some kind of pkg-
config

What to do when .pc files are not installed?

	I've thought about this one a good bit. Presently, I feel like 
the time and effort one could spend making fall back configuration 
mechanisms would be better spent .pc generation mechanisms. The common 
case first step would be to provide example .pc files for dependency X, 
where X may likely not have a .pc in an environment, and ask the user 
(package maintainer, developer, or other person building the source) to 
hand modify it as needed. This is no more strange than having to spell 
out long CFLAGS, LDFLAGS, and related vars to ./configure. An improvement 
to this would be side script(s) that generated .pc based on detection 
logic. 

	This way, all the external dependency logic is done the same way. 
If you use .pc internally, then you really are at a point that pkg-config 
is a replacement for a large set of features from autoconf and libtool. 
This is one of the core ideas behind my slow moving build system project: 
github.com/ctstover/Build-Configuration-Adjust