Boost logo

Boost :

Subject: Re: [boost] proposal - modularize Boost build system
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-06-19 15:31:22

On 06/19/17 17:32, Peter Dimov via Boost wrote:
> Releasing separately from Boost means that you now have two
> Boost versions to communicate: the version of Boost.Python, and the
> version of the preinstalled Boost against which it was built (I built,
> f.ex. libboost-python-1.65.0-1.53.0 in my CentOS 7 case.)
> This consequently affects your downstream dependencies, which also have
> to include these two versions, in addition to their own. So when a
> library X depends on Boost.Python and it's compiled against Boost.Python
> 1.65.0-1.53.0, its version would now be X-1.17-1.65.0-1.53.0. This is
> not compatible with Y-2.1-1.63.0-1.53.0, even though both are built in
> the same CentOS 7 environment.

I think, you unnecessarilly complicate things. Yes, naturally lower
level dependencies define the effective set of software that is required
for the upper level software to build, run and be tested. But it doesn't
mean those dependencies need to be reflected in version numbers (they
don't) or that the upper level software doesn't work with different
versions of the dependencies. Normally, when you release a piece of
software, you declare the minimum versions of the prerequisites -
preferably, the oldest versions that were successfully tested.

IMHO, formal dependency management is a task related to packaging, which
is specific to the packaging system. I don't think Boost should be doing
this work beyond documenting the dependencies. Let packagers deal with
the technical part of enforcing these dependencies with the means they
have in their disposal.

Boost list run by bdawes at, gregod at, cpdaniel at, john at