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

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

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. 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. 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, which I think can be done while
preserving history.

>   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', 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.
E.g. if you change the path of boost/detail/workaround.hpp files like:
"libs/filesystem/src/operations.cpp",
"libs/graph/src/read_graphviz_new.cpp" and several others need to be
updated.