Problem: MSVC lib names are too complex

[jakecobb]

Solution: Give an option to use short names
in line with what other platforms (including
mingw on windows) use.

In particular, the shared library names with
toolset and version down to the patch are not
friendly to having just the DLL updated for
e.g. security updates.

[jakecobb]

Marked draft to give time for feedback. Currently, the CMake build names things in MSVC/Visual Studio like:

libzmq-v142-mt-gd-4_3_5.lib
libzmq-v142-mt-gd-4_3_5.dll

... where all other platforms are just libzmq. Most libraries end up with simply named DLLs, which allows new ones to be dropped in as replacements without recompiling/redistributing the application for e.g. bug fixes and security patches. This current scheme prevents that because the next patch version will result in a new DLL name. Renaming a DLL and lib after the fact is possible but not simple.

In favor of the current naming scheme, it's easier to build a bunch of toolset variants and distribute them together.

This naming scheme is also a bit misleading for a couple of reasons this patch does not address:

• It uses mt which would seem to imply /MT multi-threaded static runtime is used, but in fact /MD (multi-threaded DLL) and /MDd (multi-threaded debug DLL) runtimes are used for both shared and static builds. Documentation
• It includes the toolset used to compile, which prior to VS 2015 was one-to-one with the version linked, but VS 2017 and VS 2019 now link a universal runtime, so v142, v141 and v140 are all linking the v140 runtime.

Since this naming scheme has been that way for many, I left it as default.

An alternative approach would be to allow the user to define each of these postfixes directly via CMake cache variables, but it's more cumbersome to set them all. I'm also thinking of packaging systems like Conan where it's easier to add a single option for the variant then coordinating 4 variables.

[t-b]

The naming scheme is taken from boost, explained 1 as well.

The toolset might not make sense vor VS 2015+, but for older versions it is important to have it IMHO.

[axelriet]

The current naming makes zero sense. Where is the 32 vs. 64 bit flag? ARM vs Intel? MSVC vs Intel C++? There should be two flavors: libzmq.dll and libzmqd.dll, where the d suffix denotes a debug build, and the only reason for the d suffix is to avoid inadvertently shipping a debug build. The different variants (static vs dynamic CRT, 32 vs 64, ARM vs Intel, MS vs Intel vs other compilers) must be done with subfolders.

On the same note, the debug info must always be created. For Windows that's /Zi and /DEBUG for all build flavors. The PDB matching each release must be archived (not shipped) so crash dumps and minidump can be analyzed with symbols and source. Not building with symbols makes crash dumps / minidumps largely useless, and you cannot build symbols after the fact.