Re: [boost] Radical idea for repository structure

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