On 7/05/2019 13:16, Robert Ramey wrote:
I don't think that's possible. But I don't think that's necessary. The only thing is that a user would need to install the dependent libraries he needs. One could try to make a tool to do this - but I've argued that that is a fools errand. Rather than argue that any more. I could just imagine user does the following:
a) Adds a boost header to his project. b) "installs" that header as above c) tries to build his project d) If something missing - call a) for the missing thing
at the end of that process, he has a minimal subset of boost required to support his project.
The problem with this algorithm is when (c) works when it shouldn't, because it found another version of the library somewhere else that happens to sufficiently resemble the version of the library that was actually intended. This can lead to weird runtime behaviour, mysterious future compilation failures, or "it works for me" but not someone else. The latter two should hopefully lead to discovery of the problem eventually, but the first can be quite dangerous.
To summarize, the only things we would need:
a) we need a tool to download/transform one boost library at a time.
Transform in what way?
b) optionally, it would be nice to have a dependency listing tool. FYI this is more difficult than it looks since the user doesn't all the boost libraries on his machine. Such a tool would have to trawl the boost master on github or some oneline database of headers summaries.
Most compilers can generate a list of all the headers included by a C++ file, recursively. (And so can boostdep.) The trick is that there are optional dependencies so you kinda have to start with what the user app is actually including on a header-by-header basis rather than a whole-library basis. Or at least when declaring whole-library-level dependencies it should only consider dependencies included (recursively) by the top-level convenience header file, and not those included by optional extra files, unless the app actually uses them. If a header is not found or if an obviously-Boost-library header file is found outside of the Boost library root, it probably needs to be downloaded.
c) There would likely need to be separate directory - boost tools with a couple of things in it. Some stuff would be moved from boost root to boost/tools. So the user wouldn't need the root on his machine.
I don't see why it would need to be any more complex than downloading the existing Boost superproject root and doing the equivalent of "git submodule update --init" on only the specified submodules, then running a b2 build/stage cycle (modified to cope with missing modules). Either by actually using git, or doing some equivalent with tarball/zip snapshots.