Boost logo

Boost :

Subject: Re: [boost] New dependency report
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-05 13:39:21

Le 05/06/14 19:15, Peter Dimov a écrit :
> 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:
> and mpl depends on utility:
> You can't have level 3 libraries depending on level 4.
A gree that we can not assign the strict level until all the cycles are
broken. What I'm just suggesting is to put all the libraries that form a
cycle into the same strict module
For what you report I would create a module


This macro-module can be at level 4. The libraries that depends on one
of this library would depend on this macro-module. We will see what
needs to be done to break this cycle.

If declval moves from utility to type_traits we break the
type_traits->utility dependency.
I would also move typeof to type_traits.

After this changes we will have a macro-module type_traits<=>mpl.

Other cycles will appear on higher levels, and I propose to take care of
them in the same way.


Boost list run by bdawes at, gregod at, cpdaniel at, john at