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.