This is due to the mangled include of platform.h, which was to make
CMake happy.

Solution: in CMakeLists.txt, define USING_CMAKE and then look for
platform.h in current directory if that is defined, else look in
../src/ as one would expect.

-Set signaler_port to 0 which allows the OS to find a free port, rather than crashing if 5905 is in use (https://github.com/zeromq/libzmq/issues/1542)
-Added config.hpp to the source list so it shows up in generated projects
-Remove CMAKE_BUILD_TYPE setting for generators that don't use it

fixed issue with ticket #1517 (wrong lib output name in MSVC CMake build) and apply some improvements in CMake build system

A memcpy is eliminated when receiving data on a ZMQ_STREAM socket. Instead
of receiving into a static buffer and then copying the data into the
buffer malloced in msg_t::init_size, the raw_decoder allocates the memory
for together with the reference-counter and creates a msg_t object
on top of that memory. This saves the memcpy operation.

For small messages, data is still copied and the receive buffer is reused.

This allow disable making perf-tools in Release build type
Signed-off-by: Anton Sergeev <Anton.Sergeev@elecard.ru>

Replace _zmq_COMPILER with CMAKE_VS_PLATFORM_TOOLSET; so the suffix can
be automagically generated for every MSVC compiler supported by cmake.

added version to builds
other cleanup

Solution: increased to 4096 by default for all MSVC builds, for MinGW,
and for CMake.

Note: this is a speculative change, it needs confirmation before we
can keep it. Particularly, there is some doubt that changing this in
libzmq will affect upstream applications using libzmq.dll.

This became necessary after 22d6a974

fork() support is optional and its availability is correctly detected at
contfigure time.

But test_fork was all always built, preventing build for targets that do
not provide fork() from building successfully.

This pacth fixes the CMakeLists.txt on this point.