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