Subject: Re: [boost] bpm, a tool to install a modular Boost distribution
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-01-06 11:57:43
On Tue, Jan 6, 2015 at 10:40 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
> 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
> >> 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/
> > 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
> > to build the documentation, need tools/inspect to run a local inspection
> > report, need tools/boostdep to check dependencies, so why would I ever
> > 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.
I'm fine with placing it at tools/bpm. But I would highly prefer that it
was a submodule. Like everything else is in that directory (or soon will
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk