__declspec(dllimport) added to headers for windows

[milyin]

Fix for #165 issue.
Without __declspec(dllimport) the extern const .... values are mapped incorrectly when linked to dll import library, without any diagnostics

[yellowhatter]

There is a good trick for libraries that use cmake build system. You can control your export definition by distinguishing between PRIVATE and INTERFACE includes:

macro(target_define_export TARGET_NAME)
if(${WIN32})
	target_compile_definitions(${TARGET_NAME} PRIVATE ${TARGET_NAME}_EXPORT=__declspec\(dllexport\))
	target_compile_definitions(${TARGET_NAME} INTERFACE ${TARGET_NAME}_EXPORT=__declspec\(dllimport\))
else()
    target_compile_definitions(${TARGET_NAME} PUBLIC ${TARGET_NAME}_EXPORT=)
endif()
endmacro()

It isalso possible to handle static library generation here by checking target type:
get_target_property(target_type <target> TYPE)
It will be one of STATIC_LIBRARY, MODULE_LIBRARY, SHARED_LIBRARY, EXECUTABLE or one of the internal target types.

I do not insist on this approach, but it looks like a cleaner cmake-way to define library exports.

[yellowhatter]

But this approach is applicable ONLY if your library is being integrated into other projects as source- cmake package

[milyin]

But this approach is applicable ONLY if your library is being integrated into other projects as source- cmake package

Yes, and that's why I think this approach is not suitable. I believe that it's bad practice to place any pieces of code into cmake files. User should be able to integrate library into his build system without using of our cmake scripts. I.e. from my point of view:

• setting compiler definitions with CMake - OK
• assigning real pieces of code to variables (like __declspec(dllimport) with CMAke - Wrong