[boost] [Modularization] A new approach to header modularization

Subject: [boost] [Modularization] A new approach to header modularization
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-05-27 13:06:47

I've started to put together a wiki page based on our ongoing Header 
Modularization discussions.

See http://svn.boost.org/trac/boost/wiki/HeaderModularization

I listed eight approaches to meeting the Goals/Objectives/Needs/Wants, 
and was about to identify the weaknesses of each approach when I hit on 
approach nine:

      Move (permanently) each library's root/libs/libname contents
      into root/boost/libname for the library.

In other words, instead of moving the boost/... tree headers to the 
libs/... tree, merge the libs/... tree into the boost/... tree.

For example, Boost.Filesystem is currently organized like this:

   root/
     boost/
       filesystem.hpp
       filesystem/
         config.hpp
         convenience.hpp
         exception.hpp
         fstream.hpp
         operations.hpp
         path.hpp
     libs/
       filesystem/
         build/
           ...
         CMakeLists.txt
         doc/
           ...
         example/
           ...
         index.html
           ...
         module.cmake
         src/
           ...
         test/
           ...

After the reorganization, filesystem would be organized like this:

   root/
     boost/
       filesystem.hpp
       filesystem/
         config.hpp
         convenience.hpp
         exception.hpp
         fstream.hpp
         operations.hpp
         path.hpp
         build/
           ...
         CMakeLists.txt
         doc/
           ...
         example/
           ...
         index.html
           ...
         module.cmake
         src/
           ...
         test/
           ...

In theory, the root/libs/... tree isn't needed anymore. In practice we 
might want to keep a root/libs/libname/index.html entry for each library 
so docs links don't break.

Apologies if someone already suggested this approach. It is so simple I 
can't believe someone didn't already suggest it.

Unless I'm missing something, this is the only approach that appears to 
do fairly well for all of the Goals/Objectives/Needs/Wants, and very 
well for most of them. It would require some rework of scripts and other 
setups that depend on the current organization of libs/..., but that 
seems minor compared to the long-term benefits.

Comments?

--Beman