Maybe this could be done when/if we move to Subversion, because of SVN's superior directory management. A lot of our testing and other management of Boost code is done on a per library basis. However, the product delivered to users is in a consolidated file hierarchy. The current CVS archive of the code is kept in that same hierarchy. I propose changing the version of Boost kept in our SCM system to be library based. The hierarchy could be like: General any array ... config conversion crc date_time ... variant wave Where each directory would have its own "boost" and "libs" subdirectories. (And maybe a "src" directory if we use this opportunity to move mandatory source code to a higher level.) The "General" directory is for all the administration and other files that are not part of any library. We could move each tool (e.g. BCP, Quickbook, inspect, build, etc.) to this level too. We would have to rename the directory for the Wave tool to "wave-tool" to minimize confusion. For users, we create a final archive by copying the _contents_ of each top-level directory, recursively merging the contents of repeated child directories. From their perspective, nothing has changed. Building changes radically for developers _of_ Boost code, though. They have to add the include directories for each library separately into their compiler/IDE search list. It sounds like harder work, but it's actually a good thing because it forces us to consider dependencies between libraries. It allows us to analyze each library separately. Each library can also be downloaded separately (with CVS/SVN), like we used to do a long time ago with ZIP files. I think this arrangement would synergize with the Release Overview proposal at <http://mysite.verizon.net/beman/release_overview.html>. Both proposals are supposed to help with the scaling-up of Boost. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com