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?
Question 1: Does that mean different Jamfiles are needed for releases vs SVN working copies? That is too error prone - a way would have to be found so that the same Jamfile works regardless of whether it is run against a release or a SVN working copy. Question 2: Let's say lib A depends on lib B, and B in turn depends on lib C. Does that mean lib A's Jamfile must list both B and C? If such transitive dependencies have to be listed, that's a problem because if C gets changed to depend on lib D, then the Jamfile for A, B, and C all have to be changed, and that's a mess. OTOH, if only direct dependencies have to be listed in the Jamfile, it might possibly work. Question 3: What about developers who use an IDE or traditional make files? For example, using the VC++ IDE, the "Additional Include Directories" property is currently set to $(BOOST_ROOT) and you are done. On IDE's where this sort of property can be inherited, you only have to specify that in one place, and all Boost compiles work correctly. With your scheme it sounds like every library used will require an additional include path, and that path will be different for release compared to SVN working copies. That gets old fast. Or have you figured out a simpler way? Curious, --Beman