[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [modularization] Extract xml_archive from serialization
From:       Stephen Kelly <hello () steveire ! com>
Date:       2014-09-17 20:34:01
Message-ID: lvcr7g$ub2$1 () ger ! gmane ! org
[Download RAW message or body]

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?

(putting aside that it's not clear what you mean by package, who's shipping 
what and to whom etc)

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

> 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.
 
>>> So - the degree of "modularization" cannot be determined or illustrated
>>> or
>>> measured by examining the graph above.
>> 
>> Disputed.
> 
> 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.

Yes.

> You're also suggesting that I don't think there is a problem.  That's also
> not
> 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, 
xml_archive.git

stephen@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


Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]