On Mon, Jan 5, 2015 at 9:34 PM, Peter Dimov
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