Re: [boost] CMake Announcement from Boost Steering Committee

On 7/22/2017 8:10 PM, P F via Boost wrote:

...

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.

I am very thankful for your work. When I use b2 to create the complete Boost install output files, I simply have one output directory for all 32-bit and a second directory for all 64-bit files. The Intel and Visual Studio versions, thanks to containing specific Boost release numbers live together without any issues. Has this use case been considered for a Cmake based build?

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.

For a Cmake output on Windows for both Visual Studio and Intel C++, 32 and 64-bit architectures, would it produce the correct name mangled output files? Would the 'find_package(lib)' have a chance to correctly find the Intel and Visual Studio versions as separate files?

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost