Re: [boost] To modularize, or not to modularize. What is the plan?

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