Boost logo

Boost :

Subject: Re: [boost] cmake target and binary name mangling
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-23 22:23:09

> 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, 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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at