Subject: Re: [boost] New dependency report
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-05 12:49:05
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
> It includes reverse dependencies for each module and has been
> generated from the develop branch of the super-project.
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.
* 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk