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

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, or do you mean something different?

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?

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?

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.

...

git submodule foreach 'git grep -l -P boost/detail/workaround.hpp -- include/boost | xargs sed -i "s|boost/detail/workaround.hpp|boost/config/workaround.hpp|" || echo' mv libs/detail/include/boost/detail/workaround.hpp libs/config/include/boost/config/ I think moving workaround.hpp to config is just a case of moving a line in this file:

https://github.com/ryppl/Boost2Git/blob/master/repositories.txt

Actually, we should probably create a pull request today, as it seems like a sensible and uncontroversial change to me. Perhaps also 'boost/limits.hpp' and 'boost/version.hpp'. We can leave the workaround header's path as 'boost/detail/workaround.hpp',

Yes, good point.

there are already 'detail' paths in multiple modules. The headers can be moved round within a module after the conversion.

Btw. Unless I've misunderstood the command you're using (sorry if I have), you're not updating '.cpp' files which might skew the results.

You are correct. Currently I'm only analyzing 'public dependencies'. Any dependency in the cpp files is a 'private dependency' - a build time dependency that does not propagate to users of the binary. Thanks, Steve.