On 5 January 2015 at 20:52, 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/.
You can set up a repo to build outside of the boost tree, I've done it for quickbook in the past. The problem is that when you're building documentation, boost.build expects the tools to be at the relevant location. Some of the tests run inspect in a similar manner. This is also an issue for using the tools outside of boost, since everything is in the tree, no one installs anything. The python script for rebuilding the website was meant to be really simple to use, but isn't because there's no standard way to find quickbook.
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.
Is that the case for any of our existing tools?
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.
Ideally the tools shouldn't need to be updated and rebuilt too often. Some of them are now packaged on Debian, and perhaps elsewhere, so I'd like to use that. I'd prefer to use a stable binary, even if it's a bit out of date. Boost.Build is a bit annoying in this regard because you can install a standalone version including the various jamfiles it come with, but when building anything from boost it uses the scripts from boost rather than the installation, which might not match.