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

Subject: Re: [boost] bpm, a tool to install a modular Boost distribution
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-01-05 23:56:58

On Mon, Jan 5, 2015 at 9: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?
>

I was thinking of removing tools/release when the switch to it's subrepo is
complete. To move towards only having stuff that developers and users need
in the main tree. But that's only possible because most of what's in
regression is similar in nature to the website. Which has an independent
repo.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail