On 10/4/2017 12:14 PM, Stefan Seefeld via Boost wrote:
On 04.10.2017 12:01, Peter Dimov via Boost wrote:
paul wrote:
Of course, adding the version doesn't prevent the scenario you mention. They could just reinstall a whole new version of boost 1.65 and the libraries that were built against boost 1.64 would be broken.
I'm talking about Boost libraries here, not theirs. Boost library X 1.64.0 is built against Boost library Y 1.64.0. You update Y to 1.65.0, X is now broken.
While this may be true for some (or even many) "core" Boost libraries, I believe there are enough peripheral libraries that could safely be built against multiple Boost "core" versions. And while you may not yet want to consider separating the release cycles of individual Boost libraries, I think it's a big error to design such a restriction right into the infrastructure. Not being able to build Boost libraries stand-alone (i.e., against a preinstalled set of prerequisite Boost libraries) is one of my biggest complaints against the existing Boost.Build logic.
You seem to think that without any sort of individual library versioning system whatsoever, and therefore no guarantee that a particular version of a Boost library will work with some other version of another Boost library, that distributing separate individual Boost libraries to end-users will be just fine and ducky. I don't. Nor do I think placing the burden on end-user to figure out why this will not work, when it does not, is any answer. I am not against a system where Boost may be able to distribute individual Boost libraries rather than distribute each version as a monolithic whole as it does now. But if Boost library X depends on Boost library Y, there has to be some system whereby both library X and library Y have individual versioning information and there has to be some system whereby library X version nn has to know whether or not it will work with library Y version nn, or disaster will ensue. And just saying that library X should probably work with library Y, even though both are part of different Boost releases, is not a solution for end-users IMO.
(For example, I test and run development versions of Boost.Python against various older Boost releases fairly regularly, but to be able to do that I need to use my own build system, unfortunately.)
Stefan