Beman Dawes wrote:
Rather than building dependency lists into the system (which is a fairly heavyweight approach), it might be simpler to give developers a tool to find which libraries are dependent on their library, and then leave it up to the developer how much or little they test against the dependency tree. If a developer who undertests runs the risk that a merge-into-stable request will fail, because merge-into-stable requests fail if they would cause any other library to fail.
I had something different in mind, although upward dependencies are also a topic worth considering. My goal is to prevent people inadvertently introducing dependencies into a library. When I have declared "config assert" as dependencies of "memory" (for example), commits that #include a header from a library other than config/assert/memory should cause tests to fail (they currently do not as they are run against the entire boost tree). This doesn't need to be a heavyweight approach; a simple .dependencies text file with the contents "config assert" can do. We need more discipline in partitioning headers into libraries and there are a number of speed bumps to be hit along the way, but it's possible.