Subject: Re: [boost] [cmake] Pull request announcement
From: Peter Dimov (lists_at_[hidden])
Date: 2018-09-15 16:09:18
> 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.