Rene Rivera-2 wrote
I guess I'm more of a stickler about structure then :-) I look at the (small) special cases in build scripts and I cringe. I also think that if it's a problem now, it will continue to be a problem in the future for new libraries. So it's better to have an agreed upon structure (and documentation) that we can point new authors to. This is al optional anyway. It's just that I would prefer to have *one* option instead of *N* options for each library (even if N is small).
Thinking out loud using the serialization library and date_time as a problematic test case. <code> date_time date_time/gregorian_serialize serialization/split_free serialization/serialization strong_typedef pfto access serialization/nvp ... /similar to the above but more complex </code> The short version is that including anything from boost/serialization shouldn't trigger anything from boost/archive. boost/archive is where all the havoc begins in creating a deep dependency. So someone might propose the following: a) make boost/serialization and boost/archive separate modules b) move a couple of things from the serialization library (where they don't belong) such as optional.hpp to the appropriate library. These two things would make a noticeable impact on the current dependency reports. This would mean that the module structure is still "regular" so it wouldn't have to affect your testing scripts. a) looks to be possible - but not trivial. I would raise questions about which module should contain which tests etc. A whole new round of horsing around with bjam scripts - which I really, really, really hate doing. Although when I made the library I created this division - mainly to keep the thing from turning into a huge ball of wax - this was not appreciated at the time. I don't know how many - if any - secret connections I may have made over the last 12 years. I also don't know if any such secret connections are unavoidable. This would also require some extra documentation explaining the rationale behind all this. On the upside, this document would be couched in general terms so that it would a pattern for future libraries which touch upon this problem. Basically, using this as a pattern would be the general solution and your testing setup wouldn't have any (hopefully) special cases. So far no one has proposed this. Which is OK from my perspective. I also would like to see explored (maybe on a different thread) J Maddocks observation regarding "bridge libraries" and my "bridge header" idea. Maybe it's not necessary if other libraries don't import anything from the "archive" side of the library. Maybe the boost/archive should be "private" in that it would be prohibited form being included by any other library but reserved for applications. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/To-split-or-not-to-split-or-something-els... Sent from the Boost - Dev mailing list archive at Nabble.com.