Boost Interest :
From: David Abrahams (dave_at_[hidden])
Date: 2008-07-02 14:06:36
troy d. straszheim wrote:
> 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?
Let's be brave.
> 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:
> 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.
I'm certain that it would; cygwin is POSIX.
Could you use something like python's shutil.copytree or
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/231501 to do
-- Dave Abrahams BoostPro Computing http://www.boostpro.com