Re: [boost] cmake target and binary name mangling (was: Re: CMake Announcement from Boost Steering Committee)

Subject: Re: [boost] cmake target and binary name mangling (was: Re: CMake Announcement from Boost Steering Committee)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-07-23 11:08:58

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. :-)