on Mon Sep 17 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
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.
I'm certain that's easy to arrange.
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?
We get to decide.
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.
Having to specify everything is more explicit, but more labor-intensive. It's a tradeoff. I'm not sure which one is right, but I think probably the implicit way is explicit enough.
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?
If you install the headers you can use them with a single directory in the #include path. It's also possible to use svn:externals to automate the collection of subdirectories so you can do this directly in an svn working copy. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com