On 04.10.2017 13:58, Vinnie Falco via Boost wrote:
Anyhow, I'm sorry this went off a tangent. My original point was to suggest that CMake (or any other future Boost build system) should support modular builds, rather than expect Boost.X and Boost.Y always have the same version, or be part of the same source tree.
Couldn't agree more :-) And if that is a key requirement for the next build system it should be explicitly considered as such in future deliberations. I disagree. I rather like the current system where there is the one monolithic distribution, and you have confidence thanks to the testing
On Wed, Oct 4, 2017 at 10:45 AM, Rene Rivera via Boost
wrote: that all of those libraries from the same Boost version are going to work together. Its an easier guarantee to uphold for the library author and it is easier to understand for the user.
That should be the choice of the library's maintainer. (I understand your concerns. However, the tradeoff varies depending on the amount of dependency between the given library and the rest of Boost, so I don't think there is a single optimal answer for all Boost libraries.)
To break this contract and now say that X needs version so and so of Y, and another version of Z, is I think to introduce needless complexity. I'm not opposed to the idea of modular builds (i.e. get just Boost.HTTPKit and Boost.Buffers without also acquiring Boost.Asio) but I prefer the simplicity of keeping them all at the same version. Update one, update all.
Again, let's not get carried away with how we should release Boost (which is a very different topic). In any case, this should be a conscious choice, not a technical limitation. If we don't even have the means to build libraries separately, we'll never even be able to find out whether different versions would be compatible and thus safe to use by end-users. Stefan -- ...ich hab' noch einen Koffer in Berlin...