Re: [boost] [modularization] Extract xml_archive from serialization

Subject: Re: [boost] [modularization] Extract xml_archive from serialization
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-09-17 17:24:28

Stephen Kelly-2 wrote
> 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-
> positive?

I think its a much smaller number of people.

anyone who explicitly includes date-time/serialization.hpp will know that
he has to ship the data-time-serialization.dll.

others shipping the serialization dlls now have to decide whether
to include wide-characters or not.  Now they would have to start
thinking about whether to include support for xml_archive or not.
This suggests that the serialization library should create a set of 
dlls with names like
serialization-core.dll
serialization-text_archive.dll
serialization-xml_archive.dll
...

To avoid xml_archive being a special case which is quite confusing.

Note that none of the above requires separate git repositories or
include hierarchies.  Moving the files around doesn't remove dependencies,
it diminishes the presence of false dependencies in the dependency 
tracking tool.

> (putting aside that it's not clear what you mean by package, who's
> shipping 
> what and to whom etc)
> 
> LOL - I'm aware of that.  Sorry.  This is why I'm reluctant to spend
> too much on speculative use cases - though it seems unavoidable.
> <qoute>
>> Now
>> 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?

Hmmm - in the current scheme - we're creating multiple libraries or dlls
within one git repo.  That's what we do now.

In your scheme - we also create more libraries/dlls but the the source
is organized in a separate git repo.  That's the difference.

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

Its a VC thing and also a Borland thing - though I guess that's not relevant
any more.  I guess its not a gcc or clang thing so I see now that this is a
red herring.  There is  a related issue "code visibility" gcc creates
entries
in the linking table for all entry points not just the external ones.  The 
macros autolinking also include the information so that VC applications 
can export a more limited symbol table which has some benefits.  In VC
this auto linking makes sure we pick the DLL or library with the expected
ABI since VC supports a wide variety. So the number  of DLLS or Libraries
is some multiple to what we've been talking about.  Gcc doesn't have 
this variety and I think your right so they don't have auto-linking.

>> 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?

I mean before we migrated to git implementation with submodules for
each library.

>>>> 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, 
> xml_archive.git
> 
> stephen_at_hal:~/dev/src/modular-boost/libs/serialization{(detached from 
> 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)
> 
>         modified:   build/Jamfile.v2
>         deleted:    include/boost/archive/basic_xml_archive.hpp
>         deleted:    include/boost/archive/basic_xml_iarchive.hpp
>         deleted:    include/boost/archive/basic_xml_oarchive.hpp
>         deleted:    include/boost/archive/impl/basic_xml_grammar.hpp
>         deleted:    include/boost/archive/impl/basic_xml_iarchive.ipp
>         deleted:    include/boost/archive/impl/basic_xml_oarchive.ipp
>         deleted:    include/boost/archive/impl/xml_iarchive_impl.ipp
>         deleted:    include/boost/archive/impl/xml_oarchive_impl.ipp
>         deleted:    include/boost/archive/impl/xml_wiarchive_impl.ipp
>         deleted:    include/boost/archive/impl/xml_woarchive_impl.ipp
>         deleted:    include/boost/archive/iterators/xml_escape.hpp
>         deleted:    include/boost/archive/iterators/xml_unescape.hpp
>         deleted:    
> include/boost/archive/iterators/xml_unescape_exception.hpp
>         deleted:    include/boost/archive/polymorphic_xml_iarchive.hpp
>         deleted:    include/boost/archive/polymorphic_xml_oarchive.hpp
>         deleted:    include/boost/archive/polymorphic_xml_wiarchive.hpp
>         deleted:    include/boost/archive/polymorphic_xml_woarchive.hpp
>         deleted:    include/boost/archive/xml_archive_exception.hpp
>         deleted:    include/boost/archive/xml_iarchive.hpp
>         deleted:    include/boost/archive/xml_oarchive.hpp
>         deleted:    include/boost/archive/xml_wiarchive.hpp
>         deleted:    include/boost/archive/xml_woarchive.hpp
>         deleted:    include/boost/serialization/array.hpp
>         deleted:    include/boost/serialization/variant.hpp
>         deleted:    src/basic_xml_archive.cpp
>         deleted:    src/basic_xml_grammar.ipp
>         deleted:    src/xml_archive_exception.cpp
>         deleted:    src/xml_grammar.cpp
>         deleted:    src/xml_iarchive.cpp
>         deleted:    src/xml_oarchive.cpp
>         deleted:    src/xml_wgrammar.cpp
>         deleted:    src/xml_wiarchive.cpp
>         deleted:    src/xml_woarchive.cpp
>         modified:   test/Jamfile.v2
>         deleted:    test/polymorphic_xml_archive.hpp
>         deleted:    test/polymorphic_xml_warchive.hpp
>         deleted:    test/test_mult_archive_types.cpp
>         deleted:    test/xml_archive.hpp
>         deleted:    test/xml_warchive.hpp
>         modified:   util/test.jam

Hmmm - this looks like its on your local machine.  Do you plan to commit
this?  Do you have the authority to do so?

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/modularization-Extract-xml-archive-from-serialization-tp4667615p4667686.html
Sent from the Boost - Dev mailing list archive at Nabble.com.