Proposal for development of new boost libraries under CVS

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-07-23 10:52:46

The problem:

How to allow development of new, as-yet-unaccepted libraries without
"infecting" the main CVS release trunk.

My proposal:

Alongside the boost and libs directories at the top level, we add a
directory "pre-release". Beneath pre-release, we have individual directories
for unreleased boost components. In each of these directories, there is a
subdirectory "boost" which contains the relevant headers. For example:

boost/ (top level)
  boost/
    detail/
      type_traits.hpp
      ob_type_traits.hpp
      ...
     operators.hpp
     functional.hpp
     ...
  libs/
    utility/
    timer/
    ...

  pre-release/
    iterator_adaptors/
      boost/
        iterator_adaptor.hpp
        indirect_iterator.hpp
        ...
    associative/
      boost/
        associative_vector.hpp
        ...
    pattern_matching/
      boost/
         ...
    ...

Programs and tests which need access to particular pre-release libraries may
put the appropriate directory in their include paths. For example, if the
test program for associative_vector.hpp needs to use iterator_adaptor.hpp,
it would put
    boost/pre-release/iterator_adaptors
in its #include path. That way, it can #include "boost/iterator_adaptor.hpp"
and no code will need to change if iterator_adaptors are accepted into
boost.

I realize that this probably means that the development history for
pre-release libs willl be disconnected from their post-release versions. I'm
not an expert on CVS by any means, so if there's a better approach, I'm open
to it.

Lastly, I wonder if we shouldn't find a better place for source files that
are required to support some of the headers. For example, shouldn't
random_device.cpp from the random library go in boost/boost/, right
alongside boost/random.hpp?

-Dave