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:
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://listarchives.boost.org/mailman/listinfo.cgi/boost