I'm using boost-build build to build my own code. I experimented with a structure that was similar to what you're describing. It eventually evolved into my current system which still uses boost-build, but defines no libraries. Instead, my code is split into units of much smaller size. A unit is a single cpp or hpp file. In the jamfile, each unit lists its dependencies, so that when you need the functionality provided by a given unit, it'll automatically pull in whatever else is needed. Of course the release process works the way you describe, except that it has the same file-level granularity. I am not sure if this would also work for Boost. Emil Dotchevski http://www.revergestudios.com/reblog/index.php?n=ReCode David Abrahams wrote:
A few days ago I started thinking about the implications of giving each Boost library a separate subtree of the repository, and it led me to some interesting places.
* Start with the assumption that each library has a boost/ directory containing its subset of the headers it currently has. So, for example, Boost.Python would have
boost/ python.hpp python/ ...
where "..." above is identical to the current contents of $BOOST_ROOT/boost/python/
* Our release process would merge the boost/ directories
* To test a library from a source distribution, you'd need to get the boost/ directories of any libraries it depends on into the #include path.
* This list of dependency libraries would be encoded in each dependent library's Jamfile.
* Presto, a way to explicitly declare and track library inter-dependencies! If you fail to declare a dependency in your Jamfile, your tests won't compile.
Thoughts?