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