[build2] Naming of library imports from pkg-config files

[Christopher Head]

On Mon, 31 Jul 2023 13:55:13 +0200
Boris Kolpackov <boris at codesynthesis.com> wrote:

> Now back to the special case. The goal here is to take the
> project-qualified library name and find the corresponding
> system-installed library name and its .pc file (BTW, we don't search
> for .pc files directly, rather we first find the .a/.so binary and
> then look for the corresponding .pc file; see [3] for details if
> interested).
> 
> In the ideal world, the names of the .pc files would match the library
> names and we would be able to derive their names from just
> <target-name>. In the real world, however, the .pc file names are all
> over the place. The canonical example of how detached things could be
> is zlib: the library name is libz.a/libz.so but the .pc file name is
> not libz.pc, and not even z.pc, but zlib.pc. As a result, when we
> search for the .pc file, we first try <target-name> (with and without
> the lib prefix) and then the <project-name> to cover outliers like
> zlib. So the following works as expected:
> 
> import libs = zlib%lib{z}
> 
> Now to answer the question of what one should use for <project-name>
> when the library only comes from the system (at least of now, this
> can always change in the future). The recommendation is to use the
> project name to which this library belongs. A distribution package
> name is usually a good default. But sometimes you may also need to
> make sure that it will allow you to find the .pc file, like in the
> zlib case.

Thanks for the detailed reply. I had read the general importation
section, the missing piece was how this mapped onto system libraries
rather than build2 libraries.

I’m still missing something though. Maybe I’m not understanding what
you wrote correctly, but it seems like you’re saying that build2 first
looks for a .so file based on the <target-name> part, then takes the
directory in which it found that .so file, appends /pkgconfig, uses
that as the .pc file search path, and looks for a .pc file in there
named either <target-name>.pc or <project-name>.pc. But that doesn’t
seem to agree with my experience. You gave zlib as an example where the
.pc file doesn’t match the .so file, and that’s a great example as I’m
actually using it in my current project. But not knowing what I was
supposed to do, I’m importing it as “zlib%lib{zlib}”, and this works!
Despite the fact that there is no “libzlib.so” anywhere. So build2 must
somehow be finding /usr/lib64/pkgconfig/zlib.pc anyway, even though the
“look for the .so file first” approach can’t possibly work here.

Another example is libxml2: the .pc file is
/usr/lib64/pkgconfig/libxml-2.0.pc, the .so file is
/usr/lib64/libxml2.so, but I can even do “import libs =
libxml-2.0%lib{wobble}” and it works.

Is there a fallback going on which just uses the regular system .pc
search path if the .so search mechanism fails?

It would be really nice to have the full logic written up in the build2
manual somewhere. Once I understand what it is, I wouldn’t mind writing
something up myself and submitting it as a PR, if that would be useful.

By the way, I’m using version 0.14.0 as that’s the latest packaged by
Gentoo, so if this changed in the last couple of versions, that might
be an explanation.
-- 
Christopher Head