Re: [boost] [modularization] Modularizing Boost (modularization)

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Daniel James (daniel_at_[hidden])
Date: 2013-10-18 05:05:08

On 18 October 2013 09:31, Stephen Kelly <steveire_at_[hidden]> wrote:
> On 10/18/2013 10:18 AM, Daniel James wrote:
>> On 17 October 2013 23:24, Stephen Kelly <steveire_at_[hidden]> wrote:
>>> * Phase 2 - Form some kind of 'boost core library' or 'boost feature
>>> normalization library' from the guts of existing libraries like
>>> type_traits, static_assert, config mpl and utilities.
>> I think the intent was for 'detail' to be a sort of core module, but
>> several of its headers do drag in too many dependencies. I'd be
>> inclined to move them out of detail, but that's up to you.
>>
>>> Move enable_if from utility to type_traits:
>> It might be worth breaking up modules like utility and iterator rather
>> than moving the headers into new modules.
>
> Do you mean turn them into multiple repos/packages instead of one

Yes.

>> The smaller modules could
>> still feed into your boost core/feature normalization module. Although
>> that might be too difficult to do as part of the conversion.
>
> To be clear, I propose doing most/all of these modularization changes
> before the conversion to git.
>
> Are you proposing to do them concurrently/at the asme time as migrating
> to git?

Yes, or at least before modularization is in use. But I'll go along
with whatever works for the people doing this.

>> The
>> original plan was to break the functional module up, but there was a
>> problem with doing that in the conversion, so I was going to look into
>> doing it afterwards instead,
>
> What problem was encountered?

it was here:

http://lists.boost.org/Archives/boost/2013/05/204230.php

IIUC the problem is that the modules need to be used to recreate old
versions of boost. So if hash's files were moved into a new module,
the files that are currently in libs/functional/hash would be in the
wrong place. But I think it should be fine if they're moved to
'libs/functional_hash' in the future.

>> which I think can be done while
>> preserving history.
>
> How so? Replaying the history on top of master? That's still a loss of
> history really, but it's better than a straight addition-of-current-version.

Possibly by including all the module history in each smaller module
and, if possible, rewriting the history to only include the relevant
headers (this would be done before the module is in use). This means
there will be duplicate history in different modules, but I don't
think that would cause any real problems. I admit I haven't thought
this through or done any experiments, I was leaving that for later.