On 04.10.2017 12:44, Edward Diener via Boost wrote:
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'm not sure we actually disagree. For one, I didn't mean to re-open a discussion about separating release cycles. I merely wanted to point out a limitation in the existing Boost.Build logic, and how I hope that any future build system will support stand-alone builds, so further modularization can at least be considered and experimented with.
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.
I totally agree, and I'm not sure what makes you think that I would oppose such a statement. If Boost library X depends on library Y, that dependency has to be treated just as any other dependency on third-party code: if multiple versions of Y are available, there need to be clear indications (documentation, configure & build checks, etc.) to help someone compiling binaries understand whether the combination of specific versions of X and Y is known to work or perhaps even supported. (In fact, there is a whole lot to be said about API and ABI compatibility, and Boost's notorious lack of it, but let's not get even further off on a tangent...) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...