Re: [boost] Boost CMake update

Subject: Re: [boost] Boost CMake update
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2017-10-04 17:22:18

On Wed, Oct 4, 2017 at 9:58 AM, Stefan Seefeld via Boost <
boost_at_[hidden]> wrote:

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

Not entirely sure what you are referring to... But B2 doesn't have such a
limitation. So perhaps I missed something something.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail