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
> 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
> I think moving workaround.hpp to config is just a case of moving a
> line in this file:
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk