[mpl] Proceeding with modularization
Hi, Now that 1.56 is out I believe we can proceed with modularization. I'd like to complete Boost.MPL decomposition into Boost.MPL.Core and Boost.MPL that I started some time ago. I can see two ways of doing this: I can keep the two parts in the separate git repositories or I can move Boost.MPL.Core to a sub- library within the same git repo. I'd prefer the second approach since this allows to create a single pull request and keeps the library history in one place, but maybe there are other considerations?
On 8/19/2014 6:56 AM, Andrey Semashev wrote:
Hi,
Now that 1.56 is out I believe we can proceed with modularization. I'd like to complete Boost.MPL decomposition into Boost.MPL.Core and Boost.MPL that I started some time ago. I can see two ways of doing this: I can keep the two parts in the separate git repositories or I can move Boost.MPL.Core to a sub- library within the same git repo. I'd prefer the second approach since this allows to create a single pull request and keeps the library history in one place, but maybe there are other considerations?
It would really be nice if we could cleanup MPL and get rid of all he hacks/workarounds for old compilers that nobody should be using anymore. Stephen Kelly attempted to do this on his own git branch but was voted down from getting this on to 'develop' and I similarly tried to promote his changes to 'develop' but was voted down. It is really trying to do much of anything with MPL if all of this old stuff stays around forever. Just reading the code and understanding it, in the face of these hacks is a real trial, much less changing anything. Good luck separating MPL into MPL.Core and MPL with this code still around !
On Tue, Aug 19, 2014 at 10:45 PM, Edward Diener
On 8/19/2014 6:56 AM, Andrey Semashev wrote:
It would really be nice if we could cleanup MPL and get rid of all he hacks/workarounds for old compilers that nobody should be using anymore. Stephen Kelly attempted to do this on his own git branch but was voted down from getting this on to 'develop' and I similarly tried to promote his changes to 'develop' but was voted down. It is really trying to do much of anything with MPL if all of this old stuff stays around forever. Just reading the code and understanding it, in the face of these hacks is a real trial, much less changing anything. Good luck separating MPL into MPL.Core and MPL with this code still around !
I wasn't planning to explicitly remove workarounds except only one for Borland that adds dependency on TypeTraits. The workarounds aren't the problem.
Andrey Semashev wrote:
Now that 1.56 is out I believe we can proceed with modularization. I'd like to complete Boost.MPL decomposition into Boost.MPL.Core and Boost.MPL that I started some time ago. I can see two ways of doing this: I can keep the two parts in the separate git repositories or I can move Boost.MPL.Core to a sub-library within the same git repo. I'd prefer the second approach since this allows to create a single pull request and keeps the library history in one place, but maybe there are other considerations?
I don't have much of an opinion one way or the other. Boost.Build doesn't handle arbitrary sublibs at the moment very well, I think (numeric/* is hardcoded) but this will need to be fixed anyway. This aside, if you go with a sublib, it seems to me that it will be easy to move it into a proper submodule at a later date if we so decide, unless I'm missing something.
participants (3)
-
Andrey Semashev -
Edward Diener -
Peter Dimov