Re: [boost] To split, or not to split, or something else? RE: type_traits rewrite, modularization, dependencies, etc.

Subject: Re: [boost] To split, or not to split, or something else? RE: type_traits rewrite, modularization, dependencies, etc.
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-02-04 12:37:51

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-else-RE-type-traits-rewrite-modularization-dependencies-etc-tp4671930p4672049.html
Sent from the Boost - Dev mailing list archive at Nabble.com.