$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] New dependency report
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-05 15:45:34
Le 05/06/14 19:56, Andrey Semashev a écrit :
> On Thursday 05 June 2014 19:39:21 Vicente J. Botet Escriba wrote:
>> 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.
> I don't think we should place components together just on dependency basis.
> Modules now roughly correspond to libraries that serve different purposes. I
> like the separation. Merging libraries together is a step backward to
> monolithic Boost, IMO. It doesn't remove any dependencies, it simply hides
> them.
>
>
This is temporary, and allows to help to go on the level identification.
Anyway, here is my proposal to break the mpl -> type_traits dependency
(following the Peter suggestion)
- Move to a new core_type_traits everything that make mpl depend on
type_traits
*|boost/type_traits/detail/bool_trait_def.hpp||
* boost/type_traits/detail/bool_trait_undef.hpp||
* boost/type_traits/is_class.hpp||
* boost/type_traits/is_empty.hpp||
* boost/type_traits/is_reference.hpp||
* boost/type_traits/is_same.hpp|
* boost/mpl/bool.hpp
* boost/mpl/aux_/lambda_support.hpp
* boost/mpl/bool_fwd.hpp
* boost/mpl/integral_c_tag.hpp
* boost/mpl/aux_/config/static_constant.hpp
| * boost/mpl/aux_/adl_barrier.hpp
* boost/mpl/aux_/config/adl.hpp
* boost/mpl/aux_/config/gcc.hpp
* boost/mpl/aux_/config/msvc.hpp
* boost/mpl/aux_/config/intel.hpp
* boost/mpl/aux_/config/workaround.hpp
|
|- Replace the use of boost/type_traits/same_traits.hpp by
<boost/type_traits/is_same.hpp>|
This is artificial, but it allows us to continue with the modularization
without cycles. We could do better surely, but this is one step forward.
Best,
Vicente