On Mon, Jan 5, 2015 at 3:52 PM, Peter Dimov
Daniel James wrote:
A lot of things in tools (e.g. inspect, boostbook, quickbook) aren't
needed by users, they mainly need to be there because Boost.Build expects them to be.
That is the reason. We could leave the tools in their separate repositories under boostorg without making them submodules, but they won't build unless put into tools/. And if a tool X requires another tool Y for some reason, that other tool would also need to be in tools/Y for tools/X/build/Jamfile to find it. It's certainly more convenient for people using the development source tree for the tools to be there by default, kept up to date by git pull && git submodule update --init, switched to master/develop as appropriate, and so on.
Although you are right that putting bpm into a release may not be of much use, except for users who want to look at its (officially released) source.
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? --Beman