Peter Dimov-2 wrote
<snip> These headers (along with their dependencies), or some subset of them, can be separated into a "serialization core" module.
OK then the "serialization core" needs tests - right? then wouldn't the serialization core module depend upon the archive part of the serialization library? Wouldn't that suck in the everything else as it does now. if one uses date-time but doesn't include date-time/serialization and everything works - how can one say that date-time is dependent upon the serialization library?
Doing this right might still be a significant undertaking, of course. A cursory look shows that map.hpp includes boost/archive/detail/basic_iarchive.hpp, for instance.
If one just included the header things might work - until someone needs to actually invoke the serialization of the type - at which case - either you've got a missing function when you try to link or you've had to make the serialization library dependent in any case.
On the other hand, it's possible to start with only the part that's straightforward and advance incrementally towards the goal.
For what it's worth, the serialization library namespace is already divided into "archive" and "serialization" since the very beginning with the exact idea of separating the serialization from the concept of archive. I caught a huge amount of strident criticism for doing this (much more than the current incident). But It looks to me that things are already structure more or less as you are recommending - but that this doesn't show on the dependency graph because the graph tries to implement a concept of module dependency rather than header dependency. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-Rewrite-and-dependency-free-v... Sent from the Boost - Dev mailing list archive at Nabble.com.