Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-10-18 08:23:17
On 10/18/2013 11:05 AM, Daniel James wrote:
>>> 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.
That's good, but I don't think it's a position shared by everyone :).
>>> 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:
> 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.
Thanks for the link. If any part of my plan can move forward (reading
the mail from Beman, that is not a certainty), I can look into that issue.
>>> 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).
I don't really see a sense in having a non-zero time interval between
considering a module converted to git and considering it 'in use'. As
far as I understand your mail, you want to do this splitting after
conversion, but before considering it 'officially in use' or something?
You are talking about re-writing history of a git repo. I still
recommend modularizing first.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk