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

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
> that?

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.

--Beman

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
Package Manager:-).