Re: [boost] proposal - modularize Boost build system

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.