Re: [boost] mpl_core (Was: New dependency report)

Subject: Re: [boost] mpl_core (Was: New dependency report)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-08 10:15:39

On Sunday 08 June 2014 16:54:07 Peter Dimov wrote:
> Andrey Semashev wrote:
> > Eyes are afraid, hands are doing. :) Here is my first take on this:
> > 
> > https://github.com/Lastique/mpl_core/tree/develop
> > https://github.com/Lastique/mpl/tree/develop
> 
> Thanks for doing this work.
> 
> Did you run the MPL tests on the new structure? (And if so, how - I'd like
> to do the same.)

Yes, all passed (with a lot of warnings though; I assume this is normal). Not 
surprising, given that I didn't touch the code.

I'm on Linux, so it may be easier for me if you're on Windows. What I did was:

1. Checkout my fork of MPL and MPL.Core.
2. Move BOOST_ROOT/libs/mpl somewhere else, out of the Boost tree.
3. ln -s ../../boost-mpl_core mpl_core; ln -s ../../boost-mpl mpl; I.e. create 
symlinks in BOOST_ROOT/libs for the replacement modules.
4. In BOOST_ROOT, remove boost directory and run b2 headers. It should create 
symlinks to the submodules.
5. In BOOST_ROOT, run bjam -j 8 --toolset=gcc cxxflags="-std=gnu++0x" 
variant=debug threading=multi runtime-link=shared link=shared libs/mpl/test. 
Don't run it in libs/mpl/test, bjam won't find Boost root.

I'd be curious to see a report of your boostdep tool, just in case I missed 
some dependencies in my scripts.

> I think that in this case a better way to move the files into the new repo
> will be to clone mpl into mpl_core and then 'git rm' the extra files. This
> will likely preserve the history better, and it has the additional advantage
> that you can at a later date move another file by just undeleting it.

Maybe, although it would complicate scripting as I work down from the headers 
that I want to move, not the ones I want to delete.

> Assuming that the tests are fine, I wonder what is the best way to proceed
> from here.
> 
> Do people have objections to splitting these headers into a new submodule,
> mpl_core?
> 
> My initial thought is that we can create the new submodule on a feature
> branch in the superproject, so as to not affect develop and master at this
> time. The feature branch will not automatically pick up any further
> 'develop' changes in other modules, but that's probably not a problem. (The
> changes to the existing MPL module will need to also be done on a branch, of
> course.)

I think we're safe to do this in develop. The extraction doesn't require code 
changes (yet, until we solve that TypeTraits dependency problem). However, I'd 
be fine if we do this in a separate branch and merge it after 1.56.