Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-07-22 12:25:00

> This is a case where Boost's policy of appending all of the 
> toolset/configuration/threading model etc. to the library name is 
> somewhat unique and, and generally incompatible with how the rest of 
> the world works.  In general, I've found it a hindrance to 
> interoperability, and solving a problem which I didn't have in the 
> first place.  No one else does it, and there's likely a good reason 
> for that!  At most, I add a 'd' debug postfix on Windows, and that's 
> it (this is handled by CMake as a standard behaviour).  If I need 
> multiple configurations, I build them separately and explicitly; I 
> don't expect it of the build system itself.

I had a feeling this would come up, and as the instigator of this let me 
explain how/why it happened.

A very long time ago, before Boost as it happens, I had a toy C++ regex 
library, I released it to the world and it got some exposure and 
feedback.  However, I was getting about 1 support request a week from 
folks who were linking regex built one way to an application built in 
some binary incompatible way (this is with Visual Studio). Now that's a 
lot of support requests for a library that had only limited exposure 
pre-boost, pre-github, and yes, pre-sourceforge too.  I dread to think 
how many support requests it would generate now, had this issue not been 
solved via name mangling and auto-linking when using Visual Studio.  It 
means it "just works" on a platform that has a multitude of different 
compiler runtimes, all binary-incompatible with each other.  Sorry, but 
a simple "d" suffix on Windows doesn't even begin to cover the whole 
heap of pain that results from doing this wrong.

{
Aside 1: If I were forced kicking and screaming to abandon the name 
mangling, then mangling the library namespace would mitigate this 
somewhat, but not enough IMO.
Aside 2: If the VS CMake generated files were good enough, then the 
canonical way of using Boost under Visual Studio would be to reference 
our project files from your applications solution.  Then the libraries 
your using would always be built with the same options that you're using 
in your project.... well nearly, this actually requires quite a bit of 
manual intervention to set the properties of every dependent library the 
same, plus a fair proportion of VS developers seem not to know how to 
reference an external library from their IDE anyway :(
}

In short, I simply can't express how much easier name mangling makes the 
developers life.

I can of course see that on other platforms, this makes no sense at all, 
and assuming there is "one true version" makes perfect sense.

Best, John.

---
This email has been checked for viruses by AVG.
http://www.avg.com