Re: [boost] Boost CMake update

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