On Wed, Oct 4, 2017 at 9:58 AM, Stefan Seefeld via Boost < boost@lists.boost.org> 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