Vicente J. Botet Escriba wrote:
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.
I didn't introduce the cycles, they were already there. :-) It is impossible to have a strict level definition, X depends on Y implies level(X) > level(Y) when there are cycles. That should be obvious: level(X) can't be both less than, and greater than, level(Y). So the best we can possibly do is weak level assignment, X depends on Y implies level(X) >= level(Y) from which it follows that when X and Y depend on each other, level(X) == level(Y). Basic mathematics. :-) And when you have type_traits -> mpl -> utility -> type_traits, this also implies that those three are on the same level. There is no other way that could possibly satisfy the definition. The current level assignments are slightly stronger than that, they satisfy the property that level(X) == level(Y) only when X and Y form a dependency cycle. It's not possible to do better, I'm afraid.
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.
No, because type_traits depends on typeof: http://www.pdimov.com/tmp/report-6d1f271/type_traits.html#typeof and mpl depends on utility: http://www.pdimov.com/tmp/report-6d1f271/mpl.html#utility You can't have level 3 libraries depending on level 4.