Subject: Re: [boost] [modularization] Extract xml_archive from serialization
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-09-17 16:34:01
Robert Ramey wrote:
> Since most of the problem is xml_archive->spirit - we can
> "fix" this by moving the xml_archive to ?. This will "solve"
> the problem above. Of course this comes a the expensive
> of everyone who wants to ship serialization with support
> for all of the archives classes in the package. They will now
> have to link with some other module other than serialization
> which is pretty non-obvious.
> So the net improvement in utility of boost libraries is not
> likely to be positive.
> The "correct" solution to the above is for date-time to build
> two modules: date-time and date-time-serialization.
Is this "at the expense of everyone who wants to ship datetime with support
for serialization in the package"? Is that 'non-obvious' too? Is this a net-
(putting aside that it's not clear what you mean by package, who's shipping
what and to whom etc)
> the original app user above has only what he wants and is
> not dependent upon boost serialization. Yet other users
> of the serialization library have what they want - serialization
> all in one place.
You just created a separate thing to (presumably separately) download.
What's the 'all in one place' part?
> So we have the case where applications which don't use wide character
> functionality don't have to pay for it. And those that do get this
> without having to do anything special - auto-link is fully implemented.
Isn't auto-link a VC++ only thing? Trying to assess the veracity of the
'don't have to do anything special' claim.
>>> So - the degree of "modularization" cannot be determined or illustrated
>>> measured by examining the graph above.
> LOL - and what does that mean?
It means that it is the source of our disagreement.
> Before modularized Boost
Just so I understand why you use a phrase like this, can you tell me whether
we are now 'after modularized Boost'? When did that happen? What event
divides before and after? Was the modularization 'event' migration to a
large number of interdependent git repos? Does that statement make any
sense, given the word interdependent appears in it?
> , there wasn't much we could
> do about it. Now we're looking at using modularized Boost to permit
> Boost to be made a lot bigger, this in turn raises the issue of
> deployment subsets
> and and for the first time we're starting look seriously at this.
> You're also suggesting that I don't think there is a problem. That's also
> true. But I don't buy the argument "something needs to be done, this is
> something, therefore we must do this".
That's not my argument/attitude/approach.
>>> b) created as a separate library module
>> This is the proposal.
> I'm still not quite getting what you mean by creating a separate module.
> Do you mean creating a separate module at the git level?
Yes. Locally I've moved the deleted files below into a new repo,
7f80632)}$ git status
HEAD detached at 7f80632
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk