[build2] pkgconfig files, header-only libraries, and cppget's boost packages
Michael Martín Moro
sexymimi64 at gmail.com
Thu Jan 12 11:39:19 UTC 2023
Hi !
Sorry, it took me a really long while to put this to the test...
But back then I did install the build2 staging version from october 2022,
and I just tested it today: it works as expected indeed !
El vie, 30 sept 2022 a las 6:50, Boris Kolpackov (<boris at codesynthesis.com>)
escribió:
> 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
>
--
*Michaël Martín Moro*
{ Epitech. Tek4 }
{ UCA Cadíz - Computer Engineering }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20230112/ac4496b7/attachment.html>
More information about the users
mailing list