|
Boost : |
From: Daryle Walker (darylew_at_[hidden])
Date: 2006-07-22 18:13:15
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk