Niall Douglas wrote:
As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.
Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.
Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work".
Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed.
...
So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too.
I'm not necessarily arguing against that approach, but after having heard many (both over the years, and recently) argue that CMake's "one build directory per configuration" philosophy is better than Boost.Build's multiconfig philosophy, it's amusing to see you suggest that idiomatic and modern CMake 3 is a reinvention of Boost.Build. :-)