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

From: Miguel A. Figueroa-Villanueva (miguelf_at_[hidden])
Date: 2008-07-02 16:31:52

On Wed, Jul 2, 2008 at 2:06 PM, David Abrahams wrote:
> 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:
>>
>> 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.
>
> Great!
>
>> 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
> this portably?

cmake can handle this cross-platform... if you type 'cmake -E' it will
give a list of commands that it can support. Notice: remove,
remove_directory, make_directory, and copy_directory. Through custom
commands it can be made to work in all platforms.

I use visual studio and cygwin, so I'll take a look at how it is
doing. I'll report back later on.

--Miguel