I would suggest that the CMake build for Boost should do things following the standard practices for CMake, and be as simple as possible.
I appreciate everything you've just said and the time you took to say it. But quite frankly, you're plain wrong: 1. The mangling pattern should be published with a formal regex for parsing it. It should never, ever change. 2. cmake lets external cmake override binary naming arbitrarily, so if you really want the binary to be called foo.so, you can go ahead and do that no problem because you know the mangling of the cmake target names, so you know which target sets to set properties for. 3. If you're working outside of cmake, cmake export writes config files which are of stable layout and which can be easily regex scanned for the name of the binary you need. Any bit of scripting can do this, even Windows batch. I've done this countless times, it's a really nice feature of cmake. So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name. Even I who has been at this game twenty plus years now I still accidentally link a binary compiled one way with binaries compiled an incompatible way, and then spent hours - occasionally days - scratching my head as to what is wrong. Indeed it only happened to me again a few days ago where I mixed a clang LLVM compiled binary with a MSVC compiled binary. Bad idea. Name mangling of library outputs is a universal good. It's why Boost does it, and any sane cmake does it. After all, why else has cmake generator expression support for name mangling? And if you're not doing it where you code, with respect I suggest you need a ton load more automated tooling deployed where you work, because you obviously are not doing enough testing or the right testing. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/