Subject: Re: [boost] Deprecation Policy
From: Peter Dimov (lists_at_[hidden])
Date: 2015-05-20 19:59:24
Stefan Seefeld wrote:
> On 20/05/15 07:33 PM, Peter Dimov wrote:
> > Stefan Seefeld wrote:
> >> In fact, I believe Boost.Build would be the obvious first choice to
> >> decouple fully from the rest of Boost, and release separately, but
> >> that's not my call to make.
> > Like this?
> > https://github.com/boostorg/build/releases/tag/2014.10
> > :-)
> Yes, like this. But I think for this really to work efficiently it needs
> to be taken out of regular Boost releases, as otherwise people will
> continue using the latter. (And notably, packagers who build binary
> packages (for example for all the various Linux distributions) will
> continue building boost-build packages out of Boost releases, rather than
> the stand-alone Boost.Build releases, which may well lead to confusion and
> even discrepancies.
I see a slight problem here though (one which you will also encounter when
you make a standalone release). You have to have a Jamroot somewhere in your
release. Let's say you take the current Boost and delete everything except
libs/python, Jamroot, boost-build.jam and boostcpp.jam. You do
(or whatever, I don't know where distributions install Boost.Build), but it
probably won't work. The reasons it won't is that (a) Jamroot in Boost 1.58
_probably_ requires Boost.Build 1.58, or perhaps 1.57 at minimum, and you
may have an earlier version, and (b) it currently includes a project from
use-project /boost/architecture : libs/config/checks/architecture ;
which it probably needs to implement the architecture feature.
That is, Boost.Build itself is absolutely standalone, but not all
Boost.Build releases will work with a given Boost release.
Which is very likely why distributions package Boost.Build from the Boost
release, instead of using a standalone release - it's guaranteed to be
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk