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