From: David Abrahams (dave_at_[hidden])
Date: 2007-09-17 22:46:32
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