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