[build2] pkgconfig files, header-only libraries, and cppget's boost packages

[Boris Kolpackov]

Michael Martín Moro via users <users at build2.org> writes:

> And I'm pretty sure that doesn't make sense: for instance, the lexical_cast
> boost library is header only, so the `libboost_lexical_cast.so` file will
> never exist. Hence I would assume that writing "-lboost_lexical_cast"
> anywhere wouldn't make sense. Yet the `Libs` field of the generated
> pkgconfig files are filled with such references to header-only libraries.

It doesn't make sense if you translate -lboost_lexical_cast only to
.a/.so. In build2 we translate -l to .a/.so or, for header-only
libraries, to .pc.

The underlying problem is this: header-only libraries may, in the
general case, need to convey metadata, just like non-header-only
ones. This can be additional -I/-D options, extra non-header-only
libraries to link, list of importable headers, etc. So in build2
we've "generalized" the -l option to also cover header-only
libraries.


> It makes sense to forward non-header-only dependencies of header-only
> libraries to their pkgconfig file.

While this may work for -I and -L/-l, it won't for -D (and for more
elaborate metadata, like lists of importable headers). Specifically,
consider a header-only library which exports a -D option. It is
linked by two independent non-header-only libraries which are in
turn both linked to an executable. If you "forward" this -D option
to both non-header-only libraries, you will end up with a macro
redefinition.


> And the result is that those pkgconfig files cannot be used by the
> pkg-config module for CMake.

Yes, this is a valid point.

I went ahead and disabled the generation of -l options for header-only
libraries (along with other build2-specific metadata) in the "common"
.pc file (i.e., non-.{shared,static}.pc). So now the "common" .pc file
will only contain the backwards-compatible information while the
.{shared,static}.pc files will also contain the build2-extended
information.

This change is available in the latest staged build2 version. If you
could give it a try and confirm things now work as expected, that
would be great: https://build2.org/community.xhtml#stage