Boost logo

Boost :

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

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