[boost] Identifying core features (was Re: Moving from CVS to Subversion?)

From: Kevin Wheatley (hxpro_at_[hidden])
Date: 2005-02-04 11:42:21

David Abrahams wrote:
> 
> Alan Gutierrez <alan-boost_at_[hidden]> writes:
> >     In any case, I hope you'll consider carefully, the project
> >     structure when you move away from the tag based system in CVS.
> 
> You bet.  In a codebase like ours with independent but
> moderately-coupled libraries it can get tricky.

It would appear to a semi-lurking outsider, that spending a short time
clarifying the structure of the libraries (even if just writing it
down on the main web page) would be useful anyway.

For instance, can Boost be considered as a 'Layered' structure, such
as a 'Core layer' (Test, Bind, Shared Ptr, MPL ... TR1?) with some
requirements that changing them should occur in a well structured way.
The non-core libraries then sit on top of this and should have minimal
dependancy on other things.

This appears to be the intent in general, but its not always clear
what unintentional dependancies exist. As an example if I want to get
program options compiled for IRIX, I discovered I needed to fix Bind
first, the release code can't begin to compile beyond the first error,
and after that is fixed I find that there are some program options
items that need fixing up, next to test it I needed a short Test
fixup, now I can test the rest of boost (still running the tests after
24 hours ... oh well I won't be using the machine over the weekend :-)

Now I can run things like bcp, which at a first pass needs filesystem,
lexical_cast, regex, shared_ptr, mpl, preprocessor, iterator, etc etc.
and this is fine as its not a library its a tool. I've also played
with boost for a while now so I kind of know how its put together, but
others coming to it? (I could also use doxygen and similar).

I wonder if external people comming to boost might miss this structure
being exposed to them in a clear way, perhaps improving the visibility
of tools like bcp would help this (and providing downloadable
binaries?) I certainly would recommend people to use it as its quite
scary the number of files that potentially get used indirectly if you
don't.

Kevin

(I suppose if I had a faster machine I'd spend less time commenting
and more time doing :-)

-- 
| Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this      |
| Senior Technology                     | My employer for certain |
| And Network Systems Architect         | Not even myself         |