|
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:
>
> 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.
>
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
type_traits<=>mpl<=>utility<=>typeof
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.
Best,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk