Re: [boost] Boost Development Environment proposal

From: troy d. straszheim (troy_at_[hidden])
Date: 2007-06-04 11:11:05

On Sun, Jun 03, 2007 at 06:35:29PM +0300, Peter Dimov wrote:
[snip]
> 
> That said, it might be good time for us to radically rethink the structure 
> of Boost and decouple versions from releases. Versions should be 
> per-library, and releases should be a set of versions. This separation ought 
> to be enforced on a directory tree level, as in:
> 
> boost/
>   foo/
>   foo.hpp
>   bar/
>   bar.hpp
> 
> with nothing else allowed in boost/. A separate compat/ directory would hold 
> the current contents of boost/ (header name-wise), giving people a migration 
> path.

Agree, each component C's headers should be accessible only via an
include path boost/C for the same reason that boost as a whole is
meant to be accessible only via boost/.  

There has been spotty discussion of this as it relates to source
control in the subversion threads.   

> This should probably come with a stricter dependency management approach 
> than the current "none". Each library should list its dependencies, 
> per-library tests should operate on a subtree formed by the dependencies and 
> not on the full boost/ tree, adding an additional dependency should be 
> frowned upon. We might consider introducing "dependency levels" such that a 
> level N library can depend on level N-1 libraries, but not vice versa.

Agree.  If you organize projects correctly you can get help
managing/enforcing these dependencies.  A library's headers, source,
test, need to be together in source control (in one directory) so it
is easy to version them independently.  Projects have:

(in directory BOOST_ROOT, say)

  iostreams/
    include
      boost/    # contains only dir 'iostreams'
        iostreams/
          *.hpp         # notice each project has its own include dir
    src/
      ...
    test/
      ...

  variant/
    include/
      boost/   # contains only dir 'variant'
        variant/
          *.hpp
    test/
      ...

If a component lists its dependencies as 

  DEPENDS(iostreams variant)

then BOOST_ROOT/iostreams/include and BOOST_ROOT/variant/include are
added to the compiler's search path when it is built.  Same thing
happens at link time with whatever libraries the dependencies provide.

This forces component authors to maintain their dependency
lists... otherwise their component won't compile.  It does not force
authors to keep their dependency lists neatly pruned, but oh well.
The dependency tree is easily accessible to automatic tools.  However
it is somewhat harder to navigate the sources.

> With this organization, several releases can proceed in parallel, it
> being the sole responsibility of the release manager to pick the
> correct library subset and their versions such that the result is a
> stable release. More importantly, it allows developers to
> concentrate on improving their libraries.

It becomes very easy to do many of the things in Beman's document,
like back out changes in a library high (low?) in the dependency tree
that break everything else, create arbitrary subdistributions, and
incorporate new libraries into stable releases.  The interface is
straightforward enough that users developing boost-dependent code can
easily manage their dependencies.

Things can get tedious when several libraries become coupled, and in
order to work on a 'branch', you must branch each of the individual
components.  

> Once there one could venture into the direction that packaging a specific 
> release should be the job of the installer and not of the release manager; 
> that is, Boost should package individual library versions, not a monolithic 
> .34.zip. The installer probably ought to also allow upgrading a single 
> library (or adding a new library) should the user so choose.

Yeah, I imagine you could get as fancy as you want here.

-t