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

_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Reply via email to