[Modularization] Variant -> Math and the Serialization issue
Hello, In regard to the other thread on the subject, I take the position that it should not be a problem for a module to depend on the serialization module. I also take the position that there should not be an explosion of 'serialization foo' modules. That is why I propose reducing the dependencies of serialization, so that depending on serialization is not a problem. That is why I suggested removing the dependency serialization -> spirit The improvement resulting from that is shown here: http://www.steveire.com/boost/deps-june-14/serialization.png http://www.steveire.com/boost/after-edge-removal-june-14/serialization.png So, now we need to remove the dependencies of the second graph. I draw your attention to the following dependencies: serialization ->variant variant -> math math -> [lots of stuff] If the variant -> math edge is removed, we get this: http://www.steveire.com/boost/june-15-serialization-no-variant-math.png http://www.steveire.com/boost/june-15-serialization-no-variant-math.dot which is already a significant improvement. There may be more low hanging fruit remaining. Variant depends on math for a single metafunction. boost::math::static_lcm Can something be changed to make Variant not depend on Math? Thanks, Steve.
Stephen Kelly wrote:
Variant depends on math for a single metafunction.
boost::math::static_lcm
Can something be changed to make Variant not depend on Math?
It can, but my suggestion would be to save this for after the release. The freeze on master is tomorrow. We could in principle proceed on the develop branch, but let's not rock the boat too much.
On Monday 16 June 2014 00:16:15 Peter Dimov wrote:
Stephen Kelly wrote:
Variant depends on math for a single metafunction.
boost::math::static_lcm
Can something be changed to make Variant not depend on Math?
It can, but my suggestion would be to save this for after the release. The freeze on master is tomorrow. We could in principle proceed on the develop branch, but let's not rock the boat too much.
+1. Develop is also needed in a stable state so that people are able to fix and test bugs before the release. And release managers explicitly asked to suspend modularization activity for the release period.
Le 15/06/14 21:25, Stephen Kelly a écrit :
So, now we need to remove the dependencies of the second graph. I draw your attention to the following dependencies:
serialization ->variant variant -> math math -> [lots of stuff]
If the variant -> math edge is removed, we get this:
http://www.steveire.com/boost/june-15-serialization-no-variant-math.png http://www.steveire.com/boost/june-15-serialization-no-variant-math.dot
which is already a significant improvement. There may be more low hanging fruit remaining.
Variant depends on math for a single metafunction.
boost::math::static_lcm
Peter you report doesn't show this dependency # variant ? assert^1 bind^3 config^0 core^2 detail^4 functional^7 math^11 move^4 mpl^3 preprocessor^0 static_assert^1 throw_exception^2 type_traits^3 utility^3 How is it? ^Vicente
Le 15/06/14 23:32, Vicente J. Botet Escriba a écrit :
Le 15/06/14 21:25, Stephen Kelly a écrit :
So, now we need to remove the dependencies of the second graph. I draw your attention to the following dependencies:
serialization ->variant variant -> math math -> [lots of stuff]
If the variant -> math edge is removed, we get this:
http://www.steveire.com/boost/june-15-serialization-no-variant-math.png http://www.steveire.com/boost/june-15-serialization-no-variant-math.dot
which is already a significant improvement. There may be more low hanging fruit remaining.
Variant depends on math for a single metafunction.
boost::math::static_lcm
Peter you report doesn't show this dependency
# variant ? assert^1 bind^3 config^0 core^2 detail^4 functional^7 math^11 move^4 mpl^3 preprocessor^0 static_assert^1 throw_exception^2 type_traits^3 utility^3
How is it?
Forget the comment please :( Vicente
If the variant -> math edge is removed, we get this:
http://www.steveire.com/boost/june-15-serialization-no-variant-math.png http://www.steveire.com/boost/june-15-serialization-no-variant-math.dot
which is already a significant improvement. There may be more low hanging fruit remaining.
Variant depends on math for a single metafunction.
boost::math::static_lcm
Can something be changed to make Variant not depend on Math?
Before we start reimplementing functionality: 1) There was talk of moving the compile-time-integer functionality out of Math and into Integer. 2) At some point I will probably try and re-factor Math into smaller chunks, but... * Not until after the release, and, * I want to see where this is going: at present any potential usefulness to all this modularization is frankly vaporware. I realize there is a chicken-and-egg situation here, but until we have some user-focused tools for handling dependencies it's not clear to me at least what the best/optimal form of refactoring actually is. And I only want to do it once ;-) My suggestion would be to park issues and possible solutions on the Wiki until we get the release out? John.
participants (5)
-
Andrey Semashev -
John Maddock -
Peter Dimov -
Stephen Kelly -
Vicente J. Botet Escriba