Re: [boost] CMake Announcement from Boost Steering Committee

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.