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