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 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