Le 05/06/14 03:31, Peter Dimov a écrit :
I've taken care of the
mpl -> detail detail -> iterator utility -> iterator
critical dependencies, which improved things a bit. The new report is at
http://www.pdimov.com/tmp/report-6d1f271/module-overview.html http://www.pdimov.com/tmp/report-6d1f271/module-levels.html
It includes reverse dependencies for each module and has been generated from the develop branch of the super-project.
Hi Peter, from my point of view there is something wrong on the levels report. mpl and type_traits cannot be on level 3 as they depend mutually (on libraries on level 3). typeof and utility can not be either as it depends on mpl and type_traits. The definition of level must be strict otherwise we introduce cycles. Level 3 * bind http://www.pdimov.com/tmp/report-6d1f271/bind.html ? config core static_assert * logic http://www.pdimov.com/tmp/report-6d1f271/logic.html ? config core * mpl http://www.pdimov.com/tmp/report-6d1f271/mpl.html ? config core predef preprocessor static_assert type_traits utility * system http://www.pdimov.com/tmp/report-6d1f271/system.html ? assert config core predef * type_traits http://www.pdimov.com/tmp/report-6d1f271/type_traits.html ? config core mpl preprocessor static_assert typeof utility * typeof http://www.pdimov.com/tmp/report-6d1f271/typeof.html ? config core mpl preprocessor type_traits * utility http://www.pdimov.com/tmp/report-6d1f271/utility.html ? config core mpl preprocessor static_assert throw_exception type_traits * If we create as I suggested a module that contains mpl + type_traits, as I suggested, we could have this module at level 3 and the others typeof and utility at level 4. This could be temporary, the time we reach to manage with the mpl<->type_traits dependency cycle. You proposition of making a type_traits -> mpl -> core_type_traits would break the cycle but this would take some time. I think that doing this kind of things could be useful to see clearer, where do we have cycles that must be resolved in some way. Best, Vicente