Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*

Subject: Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-05-20 04:56:22

On Friday, 20 May 2016 11:44:30 MSK Daniel James wrote:
> On 19 May 2016 at 23:35, Stefan Seefeld <stefan_at_[hidden]> wrote:
> > Fedora has been doing the same for many years. In fact, I'm not aware of
> > any Linux distro that doesn't ship individual Boost libraries, which is
> > why I have been promoting to do this modularization "inhouse", to avoid
> > to put that burden on package maintainers, and different distros to vary
> > slightly in their way to implement this, causing headaches for users on
> > those platforms.
> 
> OK, so any ideas how to do that? I assume they don't need separate
> tarballs, so maybe just some description of how to build libraries,
> which binaries require other binaries, and which files go into which
> package?

With regard to binaries, most of the information they already have. E.g. the 
dependencies are encoded into binaries themselves (Debian helper is able to translate 
that information into package dependencies; not sure about rpm or other build scripts). 
In Debian, they just know which libraries produce binaries and package these into 
separate packages. There are also special cases like Boost.Python, which has to be built 
multiple times - for each supported python version. I don't think we can provide any 
additional information to cover those special cases.

It's the headers that pose the major difficulty, since there is no easy way to discover 
what library (package) a header belongs to or dependencies between them. Remember 
that we distribute Boost as an archive with monolithic include structure.