Re: [boost] Deprecation Policy

Subject: Re: [boost] Deprecation Policy
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-05-20 23:18:54

On Wed, May 20, 2015 at 6:59 PM, Peter Dimov <lists_at_[hidden]> wrote:

> 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
>
>    b2 --boost-build=/usr/local/boost-build
>

It would just be: b2
As BB knows how to automatically find, and check for version compatibility,
a system installed BB.

(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

BB is actually fairly flexible when it comes to versions as it's something
we've had to deal with for more than a decade now. Flexible to the point of
it having some internal alternate implementations of stuff based on the BB
vs b2/bjam versions.

> (b) it currently includes a project from Boost.Config:
>
>    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.
>

Right. But it's something that is a known issue and has solutions (some
better than others). And if it's something really important to deal with we
can come up with even better solutions (even going back to the traditional
jam mode of bundling the entire thing into the exec).

Which is very likely why distributions package Boost.Build from the Boost
> release, instead of using a standalone release - it's guaranteed to be
> compatible.
>

Because it is easier to maintain is indeed why Volodya decided to go back
to including BB in Boost "directly". But it's not terribly hard to make
everything work separately.

And as I've mentioned in another thread (with Stefan) I build a personal
project that uses Boost and uses Cinder (which uses a bunch of Boost) in a
totally modular manner. I.e. I get each Boost lib individually, and only
the ones I need to build. And with some BB magic I can specify
inter-library dependencies and have it all build correctly in any variation
I want (without the variant tagging though).

Hence, it's achievable. It's just a matter of knowing the specific
requirements and implementing the support in BB.

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