[build2] pkg-config file name

[Paul Stath]

Hi Boris,

Ok.  That does make sense given the cross-platform build goals of Build2.

Is this a feature you would add in Build2?

Generate a symlink to the generated  *.{shared,static}.pc file.
The symlink target is determined by the value of config.bin.exe.lib variable.


In the meantime, is there I way I could create the symlink?
Is it as simple as creating a "broken" symlink in the source directory?
It appears from the documentation that build2 has a concept of symlinks.

---
Paul Stath
JMA Wireless



-----Original Message-----
From: Boris Kolpackov <boris at codesynthesis.com> 
Sent: Wednesday, March 18, 2020 8:05 AM
To: Paul Stath <PStath at jmawireless.com>
Cc: users at build2.org
Subject: Re: [build2] pkg-config file name

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 https://linkprotect.cudasvc.com/url?a=https%3a%2f%2f%2f%2flibz.so%2fa&c=E,1,bu1uP-Vp-rIRSpDe7AiPzAm3RkTaNC156-bX5qxLUvQEQkjhyBIL4RhN8soELvQuAUxVC5PZFL0VXjd46I6eQ6A4TKyQM6cTvm2yI40ClVw,&typo=1 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.