From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-06-04 10:51:37
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk