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

On 18 October 2013 09:31, Stephen Kelly wrote:

On 10/18/2013 10:18 AM, Daniel James wrote:

...

On 17 October 2013 23:24, Stephen Kelly 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.