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: Gavin Lambert (boost_at_[hidden])
Date: 2019-05-07 06:15:19

On 7/05/2019 15:55, Robert Ramey wrote:
>> 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.

It usually will look in the system include directories, which (on Linux) 
will quite often include some older version of Boost.

It's possible to tell it to not do that, but it's not the default and 
would require some heroics to do it successfully.  I doubt it's safe to 
assume that everybody is willing to do this.

> 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.

There's no particular reason why a b2 build couldn't do the same thing 
-- in fact it probably already does.

So whenever the user runs the "get me a Boost library" command (whatever 
that turns out to be) it probably has to run a b2 build anyway, so that 
will just happen.

>> 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.

To clarify, I don't mean that "regular users" should have to do a full 
git clone (if they wanted one, they could already do that).  But there 
are ways to tell git to only download a specific tree without any 
history, or to just use snapshot archives instead of using git itself.