PKG_CONFIG_PATH

[Malcolm Tredinnick]

On Sat, 2003-10-11 at 13:40, Ben Jansens wrote:
> On Sat, Oct 11, 2003 at 11:01:44AM +1000, Malcolm Tredinnick wrote:
> > So, again, what effect are you trying to achieve here?
> 
> I believe that in the case of compiling with a --prefix, it would be
> appropriate to have pkg-config replace its default lookup in
> /usr/lib/pkgconfig with $(libdir)/pkgconfig, this would allow you to build
> into a separate root, have 2 copies of the .pc files (/usr/lib and
> /other/root), and automatically have it select the right ones for you.

There are many reasons why this behaviour is undesirable:

Firstly, it would be inconsistent: it would behave differently to
include paths, library link and runtime load paths and so on. In all of
those cases, you add to the path with environment variables, not replace
it with the contents of whatever --prefix specified.

Secondly, it would mean you would be forced to keep two copies of every
*.pc file you might ever need for building in the separate prefix. Since
pkg-config now never looks in the directory it was built with as default
(or pays attention to PKG_CONFIG_PATH), you cannot leverage system
libraries when building in a separate prefix without having to copy over
their *.pc files. This is not an uncommon use case, but the way to do it
is in the next paragraph.

Thirdly, if you want that behaviour it is easy to simulate already: just
build pkg-config itself with the appropraite prefix setting. Then it
will look in ${prefix}/lib/pkgconfig for all of its files. You have to
copy over the system ones you need, but that may be acceptable. That is
exactly how a lot of use build sandboxed GNOME systems for testing: a
lot of build scripts build their own pkg-config binary and use that for
resolving the dependencies for the packages in that prefix.

Finally, one already gets the best of both worlds (your solution, plus
avoiding the second problem). By design, pkg-config searches directories
in a well-defined manner: it starts with the first directory in
PKG_CONFIG_PATH, proceeds through that list and then searches the system
directory. It uses the first occurence of the package you requested, so
you can override system packages with ones in your own installation
prefix. Thus setting PKG_CONFIG_PATH to the directory derived from
whatever you are about to pass as --prefix (probably better to base it
off ${libdir} in any case) before running configure will simulate the
behaviour you seem to want.

Really, if you want your own sandboxed build, it is inconsistent to use
the system pkg-config anyway; build a sandboxed version. In other cases
where you are just mixing a separate prefix with pre-installed system
packages, PKG_CONFIG_PATH works well.

Cheers,
Malcolm