Matthew Woehlke via SG15 <sg15_at_[hidden]> writes:

> On Wed, Oct 27, 2021, 22:32 Boris Kolpackov wrote:
>
> > A build system that wants to support system-installed libraries on Linux
> > will need to support pkg-config. This means that if this effort results in
> > a new format (which I believe where this is heading), such a build system
> > will now need to support both pkg-config and this new format.
>
> People, presumably involved in pkg-config, keep saying that, but it seems no
> one wants to do the work. I'm still waiting to see something using
> pkg-config that satisfies even CMake's more basic requirements without
> jumping through hoops.

To clarify, I am not suggesting changing pkg-config's core cflag/libs
functionality -- that works reasonably well for today's C/C++ libraries
and there will be (understandable) resistance to change any of that due
to backwards-compatibility.

However, the pkg-config format allows arbitrary NAME=VALUE variables.
So I suggest that we consider defining a set of variable that convey
additional information. We've tried that for C++20 modules in build2
and it worked pretty well. Here is an example:

cxx_modules = \
  hello..check=/usr/include/libhello/check.mxx \
  hello=/usr/include/libhello/hello.mxx

cxx_importable_headers = \
  /usr/include/libhello/check.hxx \
  /usr/include/libhello/hello.hxx

One advantage of going this "incremental" route is that libraries
that provide dual module/header interface would still be consumable
via the core functionality by build systems that don't know anything
about modules or these extensions.


> Hint: *full path to libraries*.

static_library_full_path=/usr/lib/libhello.a
shared_library_full_path=/usr/lib/libhello.a