Peter Dimov-2 wrote
Robert Ramey wrote:
The definition of "module dependency" is unclear to me.
The definition of module dependency that the report uses is:
module X depends on module Y if some header of X's includes some header of Y's
where "some header of X's" refers to the headers in libs/X/include.
That is, it doesn't track dependencies from libs/X/src or libs/X/test.
In other words, if someone tries to *use* X by including some of its headers, he needs (in the general case) to also have Y's headers installed, or the code will not compile.
OK - but what is the first code node? Is the users application? Is one of the tests? Is it all the cpp files in the library X? I think my biggest problem is the word "module". if I break date-time into two dlls - date_core and date_time_serialization will the "module" be one or the other or both? If date-time has a bunch of headers like gregorian.hpp etc. and one other library uses just that - is the whole other library dependent upon date-time? Does this change if one uses the popular "convenience header date-time.hpp? To me the "module" is sort of slippery and doesn't very well capture which we're concerned about. The attempt to say something which seems really natural like "library Y is a pre-requisite for library X" is, I think, a big problem. I realize you've answered it for purposes of running you dependency tool, but I don't think it's the definitive answer (I don't think there is one). That's why the reliance on this tool is leading us to difficulties. As I've said, this way of characterizing it doesn't help up in deciding what the best thing to do is. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/modularization-Extract-xml-archive-from-s... Sent from the Boost - Dev mailing list archive at Nabble.com.