mike wrote:
Well, personally I think that is backwards: Taking a new dependency should be a deliberate act that I manually document in my build file (many boost libraries already have far too many internal dependencies). Only then do I start to (directly) include headers from that dependency.
That's not really how things work in Boost, for better or worse. And of course dependences sometimes go down, not up.
But in the end, each library maintainer is of course free to reject / alter / extend the cmake file I'm going to propose.
Sure, but what we're discussing here is the ongoing maintenance of the cmake file, keeping it up to date. There's another approach; add to Travis a configuration that uses CMake to test the library, without running `b2 headers` first. Since the header links won't be present, a missing dependency will immediately cause an error due to the library not being in the include path. The problem here is that libraries often need more dependencies to run the tests, so it might not be possible to use the whole test suite as-is, but for libraries where this is an issue, we could add a dedicated "cmake_test.cpp" that's lighter but does at least test whether the library compiles at all.