[Boost-cmake] auto-modularization. Time to merge to main release branch?

From: troy d. straszheim (troy_at_[hidden])
Date: 2008-07-02 13:34:30

Saw some discussion on this...  here's the story.  I'll skip discussion 
of why one would want to do this at all :)

I believe this clears the way to check the cmake stuff in to the main 
release branch alongside everything else: everything can happily coexist 
with Boost.Build.   We no longer need to do any reshuffling of 
directories or adding svn:externals.  I suppose that could get 
political.  Thoughts?

boost_library_project now takes an argument HEADERS, which lists the 
toplevel headers and subdirs relative to boost/ that are a part of this 
component.  eg:

boost_library_project(Signals
   SRCDIRS src
   TESTDIRS test
   AUTHOR Doug Gregor
   HEADERS signal.hpp signals.hpp signals
   )

note that 'signals' above (the directory, not the header file) does
*not* have a trailing slash.

The MODULAR keyword is GONE.  All libraries are considered modular
all the time, that is if you depend on X, your include paths will always 
be appended with libs/X/include/boost.  Notice that these per-library
include paths don't actually exist in svn: all of the headers are still 
'in the monolith' toplevel boost/ directory (in fact, this directory is 
now an external pointing back to the 'main' release branch).   Things 
compile fine, since that directory is in the include path by default.

To 'automodularize' the boost tree, just

   make modularize

and those HEADERS from each library will get moved from toplevel boost/
to each library's libs/*/include/boost directory.  This currently 
requires 'rsync' and 'rm' presumably working only unixy platforms,
which should be fine, there's nothing about this that needs extensive
special testing on windows.  Who knows, maybe under cygwin it would work.

Of course this modifies your source tree:  don't check any of the
moves/deletes of header files, but in your working copy you will have a 
'modularized' boost.  If the dependences in the module.cmake files are 
set correctly, things should still compile.

All of the various necessary module.cmake files haven't been created 
yet...   this will take some doing.  But it should be interesting to 
finally see our dependency tree.

-t