Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-06-19 04:42:40

On 6/18/2017 5:15 PM, Ion Gaztañaga via Boost wrote:
> On 18/06/2017 22:45, Robert Ramey via Boost wrote:
>> On 6/18/17 1:34 PM, Edward Diener via Boost wrote:
>>> Let's be realistic, this is a real problem which only some sort of 
>>> Boost individual library versioning system for starters can hope to 
>>> solve.
>>
>> If I may be so bold as to summarize your point:
>>
>> In order to distribute boost as individual libraries as opposed to a 
>> monolithic set, individual library versioning will sooner or later 
>> have to be adopted.
>>
>> I think this is indisputable.  But I don't think we have to worry 
>> about in practice.  Whatever we do, it will take sometime to get there 
>> and, if we ever do get there, I think that adding this feature won't 
>> be a big problem.  Of course if we don't ever get there, we've got 
>> nothing nothing to worry about.
> 
> I respectfully disagree.
> 
> If you want to release your library individually, then it's no longer 
> Boost. Boost is a coherent library collection. You are free to release 
> your library individually, just like ASIO does. You'll need to somehow 
> solve dependency and compatibility issues on other boost libraries 
> yourself.

If you think about this a little more deeply I think you will understand 
that this methodology will not work.

As in:

1) You release Boost library X which uses some version of Boost library A.

2) Boost library Y is released which uses a different version of Boost 
library A.

3) The end-user attempts to use library X and library Y in the same TU.

This has absolutely nothing to do with you releasing library X and 
"somehow solve dependency and compatibility issues on other boost 
libraries yourself".

The current equivalent to this with monolithic Boost is the end-user 
using Boost 1.63 and Boost 1.64 together in his own module ( library or 
executable ). The end-user knows enough not to do this because for 
either 1.63 or 1.64 all libraries are "guaranteed" to work in tandem. 
But this can't happen with individual Boost libraries ( and their 
dependencies ) being released by themselves without any form of versioning.

> 
> If git clone is huge for Boost, then it's a git user problem, because 
> it's a decentralized VCS, just use a shallow clone.
> 
> If we further modularize Boost libraries, then someone will propose that 
> each library should choose its VCS, bug system and mailing list.
> 
> I don't like each library to use a different build tool (CMake, SCons, 
> etc...) I like the fact that I can write my test jamfile triggers the 
> creation of any dependent library just because all of them use bjam and 
> other Boost libraries are designed to act friendly with my library.
> 
> If you want to have a Boost library you need to maintain the style and 
> rules of Boost. If you want to be a standalone library then you can 
> already do that, but don't call it Boost. If we want to say those 
> standalone libraries are somewhat related to Boost, then let's invent 
> another name and define more relaxed rule for them.
> 
> Best,
> 
> Ion