Subject: Re: [boost] bpm, a tool to install a modular Boost distribution
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-01-06 11:40:42
On Mon, Jan 5, 2015 at 10:34 PM, Peter Dimov <lists_at_[hidden]> wrote:
> Beman Dawes wrote:
>> Putting tools that are not normally needed by users into the boost super
>> project either directly or as sub-modules seems like the monolithic approach
>> we are trying to get away from. Is there any reason Boost.Build can't be set
>> up to build our tools even if they are in separate boostorg repos?
> After giving this some thought, I'm actually not quite sure what we'll be
> trying to accomplish with that. Why is having the tools in $BOOST/tools/ (as
> submodules) a problem?
> As a developer, I (obviously) need tools/build to build and test, need
> tools/quickbook and tools/boostbook (and possibly tools/auto_index as well?)
> to build the documentation, need tools/inspect to run a local inspection
> report, need tools/boostdep to check dependencies, so why would I ever want
> to have to git clone each of those separately?
> What does this leave us with? tools/bcp, which is useful for users, so it
> goes into the release, tools/litre, about which I have no idea,
> tools/regression and tools/server. Hm. So which of these are we going to
> move outside of the tree, and what specific benefits will we derive from
At this point, I'm unwilling to slow bpm development while we try to
come up with a clear guideline as to what tools get their own separate
repo. So it is OK with me if you put it in tools/bpm.
PS: I'm thinking a lot about Unicode issues right now, so my fingers
keep typing bmp (i.e. Basic Multilingual Plane) instead of bpm (Boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk