Re: [boost] CMake Announcement from Boost Steering Committee

On Jul 22, 2017, at 7:25 AM, John Maddock via Boost wrote:

...

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.

Cmake generates checks for 64/32 in the version config files. So that when using `find_package(lib)` it will pick the correct binary if available. Also, I believe it will also distinguish binaries in multi-configation builds like VS which can build both debug and release.