On Wed, May 20, 2015 at 6:59 PM, Peter Dimov
Stefan Seefeld 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 >>
On 20/05/15 07:33 PM, Peter Dimov wrote: 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