On 5/6/19 8:31 PM, Gavin Lambert via Boost wrote:
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.
Not it won't. The user has some procedure for building his project. That procedure specifies where to find libraries. It doesn't look for them willy - nilly all over his machine or the net or anywhere else. It includes only what he specifies.
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?
This current directory structure for boost looks like: boost_root/ libs/ safe_numerics/ include/ boost/ include/ safe_interger.hpp But when boost is delivered to the user the same data is organized as boost_root/ boost/ safe_numerics/ safe_integer.hpp This is done by the release process. Those of use who are developing with the master branch use "b2 headers" to create a bunch of file links which constitute a map from the first version to the second version.
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.
Exactly - that's what I specified above. The procedure follows the include files not some idea of library dependencies.
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.
This procedure does not in any way depend on any notion of whole library dependencies. I've discussed this many many times. Most recently a few days ago on this list. I've maintained that it is not a valid notion.
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.
Of course. This is true regardless of whether it's a boost library or any other library. If my app needs something not on my machine, I have to find it and download it.
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). Some would disagree with you.
Either by actually using git, or doing some equivalent with tarball/zip snapshots.
Right, I've made no assumption about the download process or the repository or anything else. It's just a method which guarantees that one has what needs and only what he needs to build his project. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost