Acceptance of pkg-config and .pc files

[C. Thomas Stover]

On Fri, 28 Feb 2014 23:44:54 +0100, Дилян Палаузов wrote:

> Concerning the case:
>    "What to do when .pc files are not installed?"
> 
> Can you list modern systems, where this is the case?

Not so much systems / distros, but projects / packages that don't 
create .pc file with "make install". There are of course "many" projects 
that are this way. In other words a system where the normal .pc files are 
installed, but no .pc files exists for 1 or more things you want to use. 
Of these, there are two sets of cases where .pc might be there anyway:

A) instances where a distribution will just make one anyway and ship it 
with the package. I can not think of one now, but I swear I have seen 
this in the wild. 

B) (this ties into the next section) cases where "in-house" .pc files are 
created for simplifying builds by sticking to pkg-config logic for all 
dependencies

> 
> About the side scripts, do you mean, that packages depending on other
> packages, whose .pc files are not installed, shall create local .pc
> files based on some heuristic in configure.ac , and at the end
> pkg-config can be sure that either a system-wide .pc file is available,
> or a .pc file with the same name is available in the current directory,
> and take one of them in that order?
> 
> Or do you mean, that the system wide .pc file shall be created, based on
> some provided (and quite concrete) samples by the person who runs
> ./configure, and put them in the system-wide path?
> 

I mean the former. For an example, let us say we our application uses 
libfoo. The libfoo build system does not care about .pc files and doesn't 
even acknowledge they exist. So, people trying to build our application 
will either:
1) install libfoo from source, and have no .pc file
2) install libfoo development package from distro, and have no .pc file
3) install libfoo development package from distro, and have a .pc file 
from the package maintainer(s) adding one in there as a convenience

So my present strategy for creating this application's build system would 
be this:

A) expect that libfoo will have a .pc file, and act accordingly
B) clearly explain this in the notes/warnings/errors, and even provide 
and example libfoo.pc for someone to hand edit if they want. Explain they 
will need to update the PKG_CONFIG_PATH var for the build, or install to 
system.

C) if you wanted to be more "user friendly" create a shell script that 
checked for libfoo (possibly even using the traditional autoconf based 
checks) and then created a libfoo.pc in the build directory.

D) if you wanted to be even more user friendly, make C happen 
automatically if libfoo.pc wasn't found in the first place. Only then 
error if step C fails.

Currently, I am only doing A and B

The reason for this that then you can just base all test for the presence 
of, and tests for the compile and link flags for, entirely on pkg-config 
with both external and internal dependencies and just move on with life.

Also understand as mentioned before, that in this case I have completely 
moved all autoconf logic to the role of "helpers to" not "the core of" my 
source configuration, and replaced automake and libtool entirely.