Re: [boost] Radical idea for repository structure

From: Konstantin Litvinenko (Konstantin.Litvinenko_at_[hidden])
Date: 2007-09-18 03:39:21

Hello, David!
You wrote  on Mon, 17 Sep 2007 15:31:18 -0400:

 DA> A few days ago I started thinking about the implications of giving
 DA> each Boost library a separate subtree of the repository, and it led me
 DA> to some interesting places.

    I think about this every time I see how you fight with current release 
;)
    Reorganazing boost structure to separate libs is very very good idea, 
but require more work and rethinking, if you really want to get usefull 
results. When I faced up with same king of problem in my organization where 
I work, I came up with this:

SVN structure

 repository
     boost.config
         1.0
            ....
         1.1
            ....
         trunk
            build
            include
               boost
                  config
            src
            doc
            tests
     boost.filesystem
            1.0
              ...
            2.0
              ....
            trunk
                build
                include
                   boost
                      filesystem
               src
               doc
               test

Developer structure

  C:\Work
         same as SVN structure, but without unneeded library versions +
         Jamfile
         project-root.jam
        boost-build.jam

>From user perspective boost will be used as monolithic library

#incude <boost/config.hpp>
#include <boost/filesystem/path.hpp>

because of usage requirments in boost.config and boost.filesystem Jamfiles.

The developer Jamfile should looks like this:
    use-project /boost/config : boost.config/build//boost_config : 
<version>1.0 ;
    use-project /boost/config : boost.config/build//boost_config : 
<version>1.1 ;
    use-project /boost/filesystem : boost.config/build//boost_filesystem : 
<version>1.0 ;
    use-project /boost/filesystem: boost.config/build//boost_filesystem : 
<version>2.0 ;

This require extending boost.build to understand such constructs but its not 
evil its good. Such modification to use-project rule will give ability to 
skip parsing not used libraries Jamfiles on early stage.
Having notion of external/internal dependencies will allow to build projects 
such as

A(1.0) -internaly depends - B(1.0)-internaly depends-D(1.0)
 |----externaly depends C(1.0)-internaly depends-D(1.1)

But external/internal dependencies is very (IMO) dangerous beast. Without 
good so/dll analyzer tool it will be too far error prone, but anyway it will 
be usefull.
What about IDE users? Having such structure will kill all at once :) Without 
a tool that will generate IDEs project files this structure will force users 
do a lot more work setting up dependencies, addition include directories and 
so on. I have wrote such a tool and it was able to parse simple Jamfile and 
generate VC 8.0 project and solution. But now I am on the way of total 
refactoring :)

Thoughts?

With best regards, Konstantin Litvinenko.