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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk