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

[Michael Martín Moro]

Actually, a quick follow-up on that: I noticed that it doesn't work in
every case.

It definitely works in some: I can see that some linking options to
header-only libraries don't appear in the common pc file, while they do
appear in the static/shared ones. So there's definitely something happening
here, because that wasn't the case before.
However, there are still some cases in which header-only linking options do
appear in the common pc file. I'm working with a project composed of around
70 different packages (+ the ones imported from boost), and while this used
to be an issue for nearly all the pc files, it's now contained within only
a few of them... it _seems_ like with this new change, the linking option
only appear in pc files from packages which explicitly imported the
header-only library. But I'll have to check on this more thorougly before
making any definitive conclusion. I'll come back to you later with more
details.


El jue, 12 ene 2023 a las 12:39, Michael Martín Moro (<sexymimi64 at gmail.com>)
escribió:

> 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 }
>


-- 
*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/8bd3b85c/attachment.html>