Subject: Re: [boost] Boost CMake update
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-10-04 16:44:11
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
> (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.)