-----Original Message----- From: Boost
On Behalf Of Peter Dimov Sent: Friday, September 14, 2018 6:52 PM mike wrote:
Frankly, I don't see the advantage to split such a trivial file:
The advantage, as I already stated, is that when the dependencies change (which they do), you can just regenerate dependencies.cmake with boostdep (which can be automated) instead of editing CMakeLists.txt by hand.
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. But in the end, each library maintainer is of course free to reject / alter / extend the cmake file I'm going to propose. Again, the only important thing is to have a common naming convention for the public targets