Nat Goodspeed wrote:
I've been assuming that Julian's proposal will require, at least initially, that someone (the library maintainer, an interested volunteer) manually edit a specification in some syntax of the other libraries on which this one directly depends. That information could be informed by, but need not be identical to, the output of a tool.
In that case, Glen's suggestion only requires that the specification syntax include some way of annotating each dependency: "only for the following toolsets..."
Ah. I misunderstood. 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.