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

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2013-10-19 15:06:20

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.

> 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.

> 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).

-- Jeremiah Willcock