Stephen Kelly-2 wrote
Peter Dimov wrote:
The reason Stephen talks about splitting serialization is that adding serialization support needs only a few includes, independent of the rest of the library.
And in fact if you look through
http://www.pdimov.com/tmp/report-develop-c3bb6eb/serialization.html#reverse-...
you'll see that many, if not most, of the serialization dependencies are like that.
Yes, but Robert will not discuss splitting it.
There's no point even trying to come up with a solution until that changes, but it can be pointed to as a problem for anyone willing to listen :).
That's what I've been trying to point out for months.
I think that there's a lot more too it than "splitting serialization". a) It's not at all clear what "splitting serialization" means. Making a two new DLLS for xml_archives in the same module? That wouldn't change the dependency graph which is driving this request. Making a boost level module just for the XML archives (which use spirit which is what creates the tendencies which are of concern there? or what? Either of these is a serious undertaking - in large part to support auto-linking and who knows what other surprises. Probably the bjam test suite would also have to be re-organized. And I don't know what all else. A huge amount of work with no gain in functionality. b) One possibility would be re-implement xml_archives not in terms of spirit. This would of course be counter productive. The main problem is the concept of "dependency" as revealed in our charts is misleading. When we say one module is dependent upon another what to we mean? If the tests use Boost.Test - is the module dependent on boost test? well, that would depend on whether or not one plans on running the tests. Is serialization dependent on spirit? that would depend on whether one is going to use xml archives or not. I don't know how our dependency charting tool define dependency. Any discussion of dependency has to start with the users particular application. If my app only uses a portion of the library, only that portion needs to be there (header only library) or be build (other libraries). We're already seeing the difficulty of trying to refactor on the basis of a definition of "dependency" which is not really defined. We're chasing our tails. Step back a) A useful tool would look like: tool < list of user application(s), test suites, etc. > list of headers and/or library *.cpp files required. b) the above could be used to select modules. For example, if a user of date-time doesn't use serialization header from date-time - then his app isn't dependent upon serialization so the he doesn't need to install it. The current module graph would show that he does. c) The above would lead to the conclusion that we need the concept of a "partial library installation" which of course opens up all kinds of issues. However, I can say that what I've done in several cases is to install the *.cpp files directly into the target apps rather than linking to the pre-built library. In other words I've actually used this model to good effect. I'm not prepared right now to advocate any radical change in how we do things - but i just want to make it clear that the current approach to "minimize dependencies" is too simplistic to be helpful and in fact is harmful. This topic needs more exploration. 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.