Subject: Re: [boost] Sandbox cleanup
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-11-29 10:13:45
On 11/29/2010 3:27 AM, Vladimir Prus wrote:
> it appears that at present, our SVN sandbox is in fairly confused state. A
> fresh checkout contains objects of very different kinds, in particular:
> - 'boost' directory, that has assorted headers supposedly meant for
> - 'libs' directory, with various libraries
> - Pile of top-level directories for libraries-in-development, each
> containing 'boost' and 'libs' subfolders.
> - Subdirectory SCons, with a copy of entire Boost tree, buildable with
> - Subdirectory 'win32-doc-tools', which surely does not contain a library
> - Some directories named after specific people. It's not clear whether those
> directories contain a single future library, or several, or what.
> It seems that a straight-forward approach to fix that is to have two separate
> areas in sandbox, as follows:
> [using fixed font to read the below might work better]
> [complete branch of trunk, with changes]
> [complete branch of trunk, with SConstruct, etc]
Only that developers should use the correct structure, where the /boost
and /libs subdirectories exist under each individual library, and that
their appears to be many libraries in the sandbox that are obsolete in
the sense that the library is already in Boost but files are still lying
around in the sandbox.
How and if the latter can be cleaned up I have no idea. As for the
former, maybe Boost should enforce the fact that individual libraries
must use their own /boost and /libs subdirectory since the general
/boost and /libs directories will be removed at some future date and all
the libraries within these directories will be moved to their own
I too find the sandbox to be pretty messy, but I find it even more
annoying when proprosers of possible libraries to Boost put their code
in some other arcane place on the Internet rather than in the sandbox.
So it would be nice if the sandbox could be regularized and cleaned up.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk