[build2] pkg-config file name

[Boris Kolpackov]

Paul Stath <PStath at jmawireless.com> writes:

> When I build ODB, the build2 install step is generating a odb.shared.pc
> file. However, I would like this file to be named odb.pc.

A bit of background on what's going on here: In the general case, when we
install a library, we could be installing both static and shared variants.
And in build2, unlike in pkg-config, they can differ not only in the link
options (Libs vs Libs.private in pkg-config) but also in the compile options
(there is Cflags but no Cflags.private in pkg-config). Specifically, build2-
based libraries normally use a macro to distinguish between static and
shared builds which are used, for example, to setup DLL-importing on Windows.
So to solve this we create two separate *.pc files for each library type.

(To be precise, original pkg-config doesn't have Cflags.private but pkgconf,
which is what build2 uses, does. However, the rabbit hole is actually deeper
that just not having Cflags.private: in pkg-config these *.private variables
are in addition to and not instead of their non-private counterparts. Which
doesn't really help with the macro definition described above unless we
resort to undefining with -U the macro defined in the non-private variable
or some such.)


> After reviewing the available documentation, I can't determine how this
> can be accomplished. I'm probably missing something obvious.
> 
> Is this something I can control using the buildfile?

No, there is currently no mechanism to control the name and it's probably
shouldn't be overridable at the buildfile level since that would make it
harder for build2 to associate the library with its *.pc file (it's already
hairy enough with cases like libz.so/a calling their .pc file zlib.pc).

What we could do is create a symlink to one of them with the more canonical
name. We could probably even reuse the config.bin.exe.lib value, which
specifies the static/shared priority when linking an executable, to decide
which one it should be.