Re: [boost] bpm, a tool to install a modular Boost distribution

Subject: Re: [boost] bpm, a tool to install a modular Boost distribution
From: Daniel James (dnljms_at_[hidden])
Date: 2015-01-05 18:58:14

On 5 January 2015 at 20:52, Peter Dimov <lists_at_[hidden]> wrote:
> Daniel James wrote:
>
>> A lot of things in tools (e.g. inspect, boostbook, quickbook) aren't
>> needed by users, they mainly need to be there because Boost.Build expects
>> them to be.
>
>
> That is the reason. We could leave the tools in their separate repositories
> under boostorg without making them submodules, but they won't build unless
> put into tools/.

You can set up a repo to build outside of the boost tree, I've done it
for quickbook in the past. The problem is that when you're building
documentation, boost.build expects the tools to be at the relevant
location. Some of the tests run inspect in a similar manner.

This is also an issue for using the tools outside of boost, since
everything is in the tree, no one installs anything. The python script
for rebuilding the website was meant to be really simple to use, but
isn't because there's no standard way to find quickbook.

> And if a tool X requires another tool Y for some reason,
> that other tool would also need to be in tools/Y for tools/X/build/Jamfile
> to find it.

Is that the case for any of our existing tools?

> It's certainly more convenient for people using the development
> source tree for the tools to be there by default, kept up to date by git
> pull && git submodule update --init, switched to master/develop as
> appropriate, and so on.

Ideally the tools shouldn't need to be updated and rebuilt too often.
Some of them are now packaged on Debian, and perhaps elsewhere, so I'd
like to use that. I'd prefer to use a stable binary, even if it's a
bit out of date. Boost.Build is a bit annoying in this regard because
you can install a standalone version including the various jamfiles it
come with, but when building anything from boost it uses the scripts
from boost rather than the installation, which might not match.