Bug 48743

The same issue surfaced over in libburnia:
http://libburnia-project.org/ticket/153

Something like this would work.

# PKG_INSTALLDIR(DIRECTORY)
# -------------------------
# Substitutes the variable pkgconfigdir as the location where a module
# should install pkg-config .pc files. By default the directory is
# $libdir/pkgconfig, but the default can be changed by passing
# DIRECTORY. The user can override through the --with-pkgconfigdir
# parameter.
AC_DEFUN([PKG_INSTALLDIR],
[m4_pushdef([pkg_default], [m4_default([$1], ['${libdir}/pkgconfig'])])
m4_pushdef([pkg_description],
    [pkg-config installation directory @<:@]pkg_default[@:>@])
AC_ARG_WITH([pkgconfigdir],
    [AS_HELP_STRING([--with-pkgconfigdir], pkg_description)],,
    [with_pkgconfigdir=]pkg_default)
AC_SUBST([pkgconfigdir], [$with_pkgconfigdir])
m4_popdef([pkg_default])
m4_popdef([pkg_description])
]) dnl PKG_INSTALLDIR

Obviously, we can't enforce anyone to use this, though.

So, how does a system like FreeBSD make this work for their odd choice of pkg-config directory?

If I've run autoconf on *my* system, that'll pick up the setting of '${libdir}/pkgconfig' from *my* copy of pkg.m4, even if the FreeBSD folks have patched theirs? It'll only work if they check the project out from git and run autoconf for *themselves*?

Not quite what we were after... or am I missing something?

I had imagined that we'd implement this by adding a --print-pkgconfig-dir option to pkg-config(1) itself, and using the output of that in the configure macro. That way, it works regardless of where autoconf was run, so even when they use my release tarballs on FreeBSD it should be fine.

They pass --with-pkgconfigdir=/unnecessarily/different/freebsd/location to configure. The _default_ for your package is $libdir/pkgconfig or whatever you pass to PKG_INSTALLDIR in your configure.ac. If you pass nothing to PKG_INSTALLDIR, you're default is $libdir/pkgconfig since that's easily the most common case. But the AC_ARG_WITH part of the macro is there so anybody can specify however they want. Then you'll just use pkgconfig_DATA in Makefile.am.

There are a couple reasons we can't pass you "the right thing" at run-time from pkg-config.

1. The path pkg-config knows about was built-in and corresponds to system pathways. Maybe that's what you want, but I'm positive most people would want this to follow $prefix. I don't have any appetite for trying to munge together a $prefix and some base-ish part of /usr/libdata/pkgconfig.

2. pkg-config doesn't know if you want the arch-dependent or arch-independent location. Should I give you /usr/lib/pkgconfig or /usr/share/pkgconfig?

And, anyway, there's no real way we can get this right for all people. Just let them choose what they want.

However, there is "pkg-config --print-variable=pc_path" if you want. Not the most discoverable option, but it is in pkg-config(1).

Hm, OK. So FreeBSD would add '--pkgconfigdir' to the standard set of arguments it gives to configure? That's workable, I suppose. Except:
 
How does *its* build system know whether a package should be installing arch-dependent or arch-independent .pc files? And what if a given project actually installs *both*?

Perhaps we need two AC_ARG_WITH macros; one for each? On the basis that arch-dependent use is more common, perhaps they'd be 'pkgconfigdir' and 'noarch-pkgconfigdir' or something like that?

(In reply to comment #6)
> Hm, OK. So FreeBSD would add '--pkgconfigdir' to the standard set of arguments
> it gives to configure? That's workable, I suppose. Except:

--with-pkgconfigdir since autoconf doesn't let you add non-with/enable args, but yeah. Really it's no different than --prefix. There's a default, but you get to override it.

> How does *its* build system know whether a package should be installing
> arch-dependent or arch-independent .pc files? And what if a given project
> actually installs *both*?

It depends on the package, and this is no different than any package in fedora, for example. In my experience it's pretty unusual for a package to install both arch-dependent and arch-independent packages. I've done work on Xorg, and each package is pretty clearly arch-dependent (libraries) or arch-independent (data or most protocol headers).

> Perhaps we need two AC_ARG_WITH macros; one for each? On the basis that
> arch-dependent use is more common, perhaps they'd be 'pkgconfigdir' and
> 'noarch-pkgconfigdir' or something like that?

I suppose that's the way to go. Perhaps PKG_INSTALLDIR and PKG_NOARCH_INSTALLDIR where they default to $libdir/pkgconfig and $datadir/pkgconfig, respectively. The vast majority of packages would just add PKG_INSTALLDIR, but some would need PKG_NOARCH_INSTALLDIR and some would need both. Distro packagers could then pass --with-pkgconfigdir and --with-noarch-pkgconfigdir blindly and ignore warnings. For noarch .pc files, they'd need noarch_pkgconfigdir_DATA in Makefile.am. I just tested it locally and it seems to work.

(In reply to comment #7) 
> It depends on the package, and this is no different than any package in fedora,

TBH it's the Fedora packaging that I'm thinking of; the %configure macro just sets a whole bunch of stuff, and the individual package specfiles mostly don't need to touch that. I know little of FreeBSD packaging except that they do this strange thing with the pkgconfig directory, they patch the shipped Makefiles in various packages to support it (including mine as described in comment 0), and that that solution really sucks.
 
> I suppose that's the way to go. Perhaps PKG_INSTALLDIR and
> PKG_NOARCH_INSTALLDIR where they default to $libdir/pkgconfig and
> $datadir/pkgconfig, respectively.

Sounds good; thanks!

Once a version of this is in upstream pkgconfig, I'll drop it into my own acincludes and the FreeBSD folks can use it across the board. Adoption by other packages can happen whenever; at least the FreeBSD folks will have patches that it's *sane* to push to upstream then.

Fixed in 5fc77a9. The new macros are PKG_INSTALLDIR and PKG_NOARCH_INSTALLDIR.

Thanks. This is now fixed in OpenConnect, with backwards compatibility so it works without the latest pkg.m4 available:

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/372bd3daf