Subject: Re: [boost] To modularize, or not to modularize. What is the plan?
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-05-07 03:55:40
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:
But when boost is delivered to the user the same data is organized as
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
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
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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk