Acceptance of pkg-config and .pc files

[Дилян Палаузов]

Hello,

my question wasn't, if pkg-config can be enforced by configure.ac with 
PKG_PROG_PKG_CONFIG, and the consequences.

Concerning the case:
   "What to do when .pc files are not installed?"

Can you list modern systems, where this is the case?

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?

Greetings
   Dilyan

On 25.02.2014 18:12, C. Thomas Stover wrote:
> 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
>
>
>
> _______________________________________________
> pkg-config mailing list
> pkg-config at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pkg-config
>