Use of pkg-config

[Richard Purdie]

On Wed, 2014-05-14 at 19:33 +0200, Werner Koch wrote:
> On Wed, 14 May 2014 17:59, richard.purdie at linuxfoundation.org said:
> 
> > Its worth highlighting that pkg-config has now standardised on using its
> > own internal glib code so it no longer has that dependency, its handled
> 
> Okay.
> 
> > of sense. Since that is now addressed does that help improve the
> > situation to a point its use could be reconsidered?
> 
> Request an addition to POSIX and I will reconsider it.
>
> > Alternatively, could pkg-config be added as an option? It could be used
> > by default and things could then fall back to the -config scripts?
> 
> No.  The configure script along with the autoconf macros is how the
> gnupg related stuff is to be build.  If there is a problem, please file
> a bug.  Frankly, I don't see the reason for the request to use
> pkg-config.  The *-config script approach is much more flexible and
> easier to maintain.

Let me explain the problem. I lead a cross compiling build project
(OpenEmbedded/Yocto Project) so I have some experience at cross
compiling.

When we build libfoo with libdir=/usr/lib (since this is where the
library will live on target), we install it into a DESTDIR so it ends up
in DESTDIR/usr/lib/libfoo and DESDIR/usr/bin/foo-config. We want to do
two things with these files, package them up and use them on target and
also, install them into our sysroot that we're using for cross
compiling.

On target, if we run foo-config, it returns things like -L/usr/lib (as
its a default search path it may well get suppressed but you get the
idea). This is all well and good.

The trouble is that within our cross envrionment where its within the
sysroot, it will also return -L/usr/lib and this is the build system,
not the target system and causes us all kinds of issues.

We basically have two options:

a) Build things twice, once with sysroot paths and once for the target.
That is rather inefficient and isn't always successful either.

b) Hack the -config scripts in one/both cases to ensure the right paths
get added in.

We do b). We get all kinds of problems as -config scripts vary in
quality and don't have a standard way of doing things. Some may suppress
the default linker paths for example, some may not. We have cases where
we build libc in a different location than /usr/lib (e.g. for x32 ABI
support in libx32) and many of the gnupg -config scripts have
assumptions about the default linker search paths for example. We have a
multilib setup that uses lib32 which your -config files don't cover.

By comparison, pkg-config addresses our problems. It has a mechanism to
specify if a sysroot is being used and knows to prepend paths with that
if its set. It understands how to extract the default search paths from
the toolchain so it knows which can be suppressed and which should not.
We've had to teach one tool about these things and then it gets applied
everywhere in a standard way.

I understand you can't just drop -config scripts however allowing
pkgconfig as an option would make the lives of those of us doing cross
compiling much easier.

Cheers,

Richard