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@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-s... Sent from the Boost - Dev mailing list archive at Nabble.com.