On 10/19/2013 6:22 AM, John Maddock wrote:
Trying to get this discussion somewhat back on track...
There are many libraries in Boost that have "glue" headers: by this I mean small headers that allow library A to interoperate with library B. Often these are simply specializations of traits classes or function overloads, are relatively trivial, and are not included unless you need them to be. By this I mean that: suppose library B wants to interoperate with lib A. It defines a special header which #includes what it needs from lib A and defines whatever specializations are required to get the two libraries working together.
Now here's the thing: there is no dependency from lib B to lib A *unless you are already using both libraries*.
A good example would be the serialization lib: a simple dependency tracker would show this up as a dependency to a large part of Boost, but in fact that's not true: in the vast majority of those cases there is no such dependency unless you actually want to use both libraries together and do so by including the "glue" header.
So where does the glue header belong?
In most cases if you want B to interoperate with A then you define a header which:
* Includes headers from both libraries. * Uses the public interface of A, but may access the internals of B (think serialization).
Which would imply that the header belongs with B. Pure and simple. Except it's not, because these two libraries may be peers, and interoperability may be more complex than simply unidirectional.
I don't have an answer here, but it seems to me that "dependency" is a more complex thing than simply what-includes-what (and that's without getting into header file, vs source file, vs test file dependencies).
I agree with what you have said and therefore in some cases it becomes wrong to simply move files from one place to another based on a graph of header file dependencies. Individual libraries need to be considered. Regarding the property_map library I was wrong in not noticing that it does indeed including graph library headers but I believe I am correct in that its files, in a proposed modular Boost, should not be moved with those of the graph library. Property maps are an independent concept from graphs, even if used by the graph library. I am actually doing work locally with the property_map library in order to move the graph-related distributed headers and specializations to the graph library and will report on my results when I am finished. These may indeed be "glue" headers but I will argue when I am done, if I am successful, that they belong with the graph library.