Re: [boost] Boost CMake update

Subject: Re: [boost] Boost CMake update
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-10-04 16:58:52

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