Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-07-22 12:22:50
On 07/22/17 15:06, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>
>> When Boost is packaged though, it is typically compiled in just one
>> configuration, so a single set of binaries is packaged and then
>> installed in the end user system.
>
> Everyone seems to do it differently.
>
> Fedora:
>
> /usr/lib/libboost_filesystem.so.1.63.0
>
> CentOS 7:
>
> /usr/lib64/libboost_filesystem-mt.so.1.53.0
> /usr/lib64/libboost_filesystem.so.1.53.0
Those are probably the runtime packages. -devel packages should provide
libboost_filesystem.so, which is a symlink to the full name with the
version. pkg-config files are also installed with the -devel packages
and contain flags that refer to the short names (i.e.
libboost_filesystem.so).
The -mt variant is uncommon though. I think, it is usually the default
one and the single-threaded variant is not provided. Anyway, the -devel
package could provide two .pc files - one per library variant.
> Ubuntu Trusty:
>
> /usr/lib/x86_64-linux-gnu/libboost_filesystem.a
> /usr/lib/x86_64-linux-gnu/libboost_filesystem.so
Right, that's what the -dev package provides. It depends on the runtime
packages, which provides libboost_filesystem.so.<boost_version>.
> That's not our problem though, we don't have control over that. What
> we'd need to do is generate .pc files on `b2 install`, and the number of
> files this would produce is not known ahead of time, it depends on the
> options the user gives.
Sure. I'm just saying that for .pc files we could follow te same route
as we do with binaries now.