Re: [boost] Radical idea for repository structure

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-09-18 11:12:24

David Abrahams wrote:

> 
> on Mon Sep 17 2007, Vladimir Prus <ghost-AT-cs.msu.su> 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?
>>
>> Which problems with the release process such an organization
>> would solve?
> 
> I wasn't suggesting it as a way to solve problems with the release
> process.  However, having explicit dependency declarations would
> probably make efficient incremental testing more practical, because
> we'd know exactly which libraries needed to have tests run for any
> change.

"Probably"? The only problem with incremental testing now I know
are stale results, which is quite separate.

>> This organisation clearly requires some work to implement, so it
>> should give some real advantage in return.
> 
> So far it's just an idea that seems like it has potential
> organizational benefits.  It certainly would make it easier to move in
> libraries from the sandbox.

For me, it seems like there's zillion ways to organise SVN, which were
discussed for about month. That's good, but I don't see SVN organization
is the particular important thing, given that many projects are doing
just fine with relatively straight-forward organization.

I worry that yet another round of "how to place files in SVN" discussion,
will distract from real problems.

- Volodya