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

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-10-18 04:31:53

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