WIP: shared libs: export classes with functions implemented in .cpp files

[amurzeau]

When building a DLL on Windows or building a shared library with -fvisibility=hidden on Unix, class with functions implemented in a cpp file must be exported.

This mean __declspec(dllexport) on Windows, and __attribute__((visibility(default))) on Unix.

Changes made:

• UVW_EXTERN on all non templated classes.

• Declare UVW_EXTERN in config.h.

• Put UVW_EXTERN on all extern explicit template instantiations.

• Put UVW_EXTERN on instantiation of Flags<T> from an exported template. MSVC was throwing a C4251 warning for these, so I'm exported them too via an explicit template instantiation. This is not required for the code to link in fact.

• Also add UVW_MSVC_WARNING_PUSH_DISABLE_DLLINTERFACE() for MSVC as it outputs many C4251 warnings when an exported class uses a non exported template in the standard library. This means the user of the DLL must use similar enough compiler and flags so the C++ ABI is the same. There are these macro in all headers so the warning is still enabled for user code, if the user happen to use __declspec(dllexport) too.

• Almost all exported classes derive from a template class. This doesn't trigger warning C4275 because the base template class use the derived class in its template arguments. See last point here: https://docs.microsoft.com/en-us/cpp/cpp/general-rules-and-limitations?view=vs-2019

• Change tests link libraries to use uvw-shared and uv-shared instead. So this will test that functions are really available from the DLL/.so.

• Add CMake code to declare USING_UVW_SHARED or BUILDING_UVW_SHARED as appropriate.

• Enable CXX_VISIBILITY_HIDDEN so only explicitly exported symbols are exported.

Currently not working because of static variables in Emitter<>::next_type() and Emitter<>::event_type<>().

Fixes: #196

[stefanofiorentino]

Currently not working because of static variables in Emitter<>::next_type() and Emitter<>::event_type<>().

@amurzeau I have spent some time trying avoiding the monostate pattern causing your testing errors. Just for the readers, this kind of issue arises because with dynamic linking your monostate's statics are two, one in the DLL and one in the executable, so your events don't match any event in the DLL and viceversa. An available solution to this is to move events creation to compile-time (generating a lot of different types of Emitter<>::Handlers). Regrettably this has several drawbacks: majors are the cardinality of the set of different Handlers and the need of the /bigobj flag under MSVC. I think I'll give up on this for a while waiting for more inspiration (i.e. for a better solution). Meanwhile we should use the static linking (imho best linking method anyway).

@skypjack I don't know if you want to close this PR as won't do. Choice is yours.

[skypjack]

I'm implementing yet another approach that makes the event identification somewhat portable across boundaries. I've not much bandwidth, so it may take a while, but still. We can close the PR, we've an issue anyway so as not to forget to work on this. 😉