Peter Dimov wrote:
Nat Goodspeed wrote:
Manually specifying dependencies is probably better than nothing. It has two significant drawbacks though. First, it's easy to get them wrong. I've been surprised a number of times by boostdep.exe when it uncovered a dependency of which I wasn't aware.
Second, even if you get them right at first, it's easy for them to become wrong. Adding an #include to fix a bug is something that few of us think about twice. This will be especially relevant for libraries maintained by the CMT, although I don't intend to single these out; ordinary maintenance is bound to introduce dependencies by mistake for the same reason it's easy for humans to get dependencies wrong in the first place.
And even if the library is not touched at all, a header can migrate from module A (marked a dependency) to module B (not marked as such).
For these reasons, manual specification of dependencies can be reliable only if these specifications are tested as part of the regression tests. That is, if the tests for module X operate in an environment in which only the stated (and transitive) dependencies of X are present.
I don't think the dependencies need to be listed manually *necessarily*, even initially, because Stephen Kelly also generated his (module-level) dependency graphs automatically if I'm right. It is true that I didn't rule out the possibility, however. You raise a valid concern. Testing whether all necessary dependencies are included was part of my plan, but I didn't mention it yet because I considered it a detail that could be covered after we agree that modularization should be finished. -Julian