Re: [boost] [modularization] Modularizing Boost (modularization)

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-10-19 16:35:45

On 10/19/2013 3:06 PM, Jeremiah Willcock wrote:
> On Sat, 19 Oct 2013, Edward Diener wrote:
>
>> On 10/19/2013 1:58 PM, Jeremiah Willcock wrote:
>>> On Sat, 19 Oct 2013, Edward Diener wrote:
>>>
>>>> On 10/19/2013 3:31 AM, Stephen Kelly wrote:
>>>>> On 10/19/2013 02:51 AM, Edward Diener wrote:
>>>>>> I realize this is more than just moving a file, but rather involves
>>>>>> moving the specializations of property map templates for the
>>>>>> distributed property map out of their places in property_map to some
>>>>>> place under graph. I also realize that this may be beyond what you
>>>>>> have tasked yourself to do,
>>>>>
>>>>> It could be better and doesn't seem like unreasonable effort. If we
>>>>> ever
>>>>> get that far, I'd look into that, yes.
>>>>
>>>> I am working on this and will post a message about the results when I
>>>> am finished locally and have tested it.
>>>
>>> Please keep me posted on that as well (and it would have been nice to
>>> have a subject line specifically on Graph and PropertyMap issues).  I
>>> suspect that the underlying communication layer used by the parallel
>>> graph and property map libraries can be pulled out; it is in the graph
>>> library right now, leading to the dependency.  There also seem to be
>>> more general utilities (untracked_pair and unsafe_serialize, for
>>> example) that might belong in Boost.Serialization instead of the graph
>>> or property map libraries.  Looking through the other graph headers used
>>> in distributed_property_map.hpp (which is the one with the most
>>> dependencies), they can either be moved to boost/property_map/parallel
>>> since they have no other dependencies themselves, or (in the case of
>>> hash<edge_desc_impl>) moved into the graph library.  I am also willing
>>> to make those changes if you want.
>>
>> I did notice that you were the person who created the
>> distributed_property_map.hpp, but I did not know what your e-mail
>> address was so I did not try to contact you about it.
>>
>> My work has been to move distributed_property_map.hpp and .ipp into
>> the graph/parallel directory and add into that directory a
>> distributed_iterator_property_map.hpp and a
>> distributed_vector_property_map.hpp taken from the property map
>> specializations in property_map's property_map.hpp and
>> vector_property_map.hpp, while removing the specilizations code from
>> the latter two. Also the paths in graph tests would change to pickup
>> these new locations. All this would effectively remove any dependency
>> on graph from the property_map implementation.
>>
>> I am not changing any code whatsoever, just moving things around, and
>> then I am going to run the property_map tests and graph tests to make
>> sure I have not broken anything.
>>
>> I did not think to move any of the other files you mentioned into
>> property_map itself from the graph library, as I was only considering
>> the minimum way of achieving the separation.
>
> I had thought going the other way would be better: the files in
> Boost.Graph that property map code depends on don't themselves use much
> other graph code.  Thus, they can be moved to Boost.PropertyMap without
> too much work, and that keeps all of the property map types that are
> there now in that library.  There are other property map types
> (sequential and parallel) in Boost.Graph that should likely also be
> moved even though they don't need to be for dependency reasons.

If you do that it looks like you are then keeping a dependency for 
property_map on multi_index, serialization, and optional. I am not 
saying this is wrong if you feel that a distributed_property_map really 
should be part of property_map, since those addititional libraries are 
very useful for Boost libraries. I just wanted to point that out. 
Whereas the more normal non-distributed property map does not need to 
use those libraries AFAICS.

Another option is to have distributed_property_map be a separate libray 
of its own. More work, obviously, but this would create a more minimal 
set of dependencies for property_map itself.

>
>> I do think that if one is specializing some class template in library
>> A whose dependencies in the specialization code are in library B that
>> the way to do this is to put the specializations in library B since an
>> end-user of that particular specialization must "use" library B anyway
>> to have the specialization work properly. Likewise I don't think that
>> graph serialization code belongs in serialization but rather in graph.
>
> The graph serialization doesn't, but there appear to be some utilities
> in there that are not specific to graphs and that might be useful for
> other Boost.Serialization or Boost.MPI users.
>
>> Any help you can give or advice is clearly welcomed, but I think I can
>> get this done on my own without really having to understand, which of
>> course you do since you wrote it, the distributed_property_map code
>> and specializations based on it.
>
> For the record, I didn't actually write it; I put it in and am
> maintaining it now.

Thanks for the information.

>
>> My goal is purely to have property_map be not dependent on graph since
>> it is its own concept. I have a use for property_map totally outside
>> of any use for graph in a library I am still developing, thus my own
>> willingness to do this work.
>
> I agree with your goal, but I think it makes more sense for
> distributed_property_map to be in PropertyMap rather than Graph (with
> its dependencies moved there as well).

If you feel that is the way it should be please go ahead and implement 
that change. My goal was to make property_map not dependent on graph.