Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Robert (r.firl_at_[hidden])
Date: 2017-07-26 17:08:08

On 7/22/2017 8:10 PM, P F via Boost wrote:
> 
>> On Jul 22, 2017, at 7:25 AM, John Maddock via Boost <boost_at_[hidden]> 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
>