On 5/30/15 3:29 AM, Peter Dimov wrote:
Robert Ramey wrote:
Why would anyone want to use this? and for what?
It's a Linux thing.
On Linux, you do
apt-get install boost
and you get a pre-built Boost release (1.55.0, for example, for the current Debian/Ubuntu distributions) automatically downloaded and installed into the system header and library locations.
So if you then want to upgrade just Boost.Python, you could in theory download a standalone Boost.Python release and build it with the system-installed Boost.Build, against the system-installed dependencies such as Boost.SmartPtr.
On Windows (and, I suppose, OS X), there's no such system-supplied Boost, so the above doesn't apply and Windows people don't see a point, in a similar manner to how Linux people can't see the point of bpm.
OK - this is making some more sense to me now. If one uses apt-get to install the total boost package, it installs in the system libraries. So if one want's to paste his own library or updated library into the system, you have to muck with stuff you don't want to. In creating the Boost Library Incubator I wanted to make it easy to download/clone a library and run it with the current boost implementation. After some experimentation on my OSX system I came to recommend the following build/test with CMake/CTest to a directory outside the boost directory. The CMake script uses Find to find the boost installation and set up the include and other paths. This avoids the whole bin.b2 directory structure so it's a simpler albeit less powerful than Boost Build. But one does endup with a library structure which works with boost and is only missing bjam files for build and test in order to fit in the official boost structure. Soo ... it seems that what would be interesting would be the facility to use boost build outside the boost structure - something we don't have yet. This would permit building/testing adding a new library or overriding the downloaded one with a newer version. Have I got this right? Robert Ramey