Static library support improvements

[past-due]

• #define UTF8PROC_STATIC to disable DLLEXPORT
  • This is a simplified subset of ability create static library #85 (also, see: Would like to be able to disable DLLEXPORT #96) that enables compiling utf8proc without DLLEXPORT - without requiring the library consumer to modify the source files.
  • Simply #define UTF8PROC_STATIC when compiling to disable DLLEXPORT.
• [CMake] Automatically define UTF8PROC_STATIC if BUILD_SHARED_LIBS is off
  • This extends automatic definition of UTF8PROC_STATIC to CMake builds based on CMake's BUILD_SHARED_LIBS status, thus automatically handling shared / dynamic / static builds.
• [Makefile] Support additional UTF8PROC_DEFINES
  • This can be used to specify flags like -DUTF8PROC_STATIC without modifying CFLAGS / environment directly.
  • Simply define UTF8PROC_DEFINES=-DUTF8PROC_STATIC when calling make on utf8proc.

[stevengj]

One issue here is that people using utf8proc.h on Windows seem like that have to #define UTF8PROC_STATIC before #include <utf8proc.h> if they are linking the static version, as otherwise the declarations will have __declspec(dllimport) decorations. Is there a workaround?

[past-due]

@stevengj: That is required, yes, but there are several other projects that do this. (Additionally, this is no worse than the current status-quo, where folks are editing the files manually to accomplish the same thing.)

However, if they are using CMake, this patchset takes advantage of the PUBLIC specifier of target_compile_definitions. Assuming dependencies are set up properly, all code that depends on utf8proc will inherit the UTF8PROC_STATIC define automatically (if building a static lib). So there is no need to manually define UTF8PROC_STATIC before #include <utf8proc.h> when using CMake and its BUILD_SHARED_LIBS setting.

(I'm not familiar with similar functionality for makefile builds, but this patchset does NOT add that define automatically in any case for those - it just adds the ability for the developer to do so without having to edit this project's files / makefiles.)

[stevengj]

Fair enough. In any case, the situation on Windows certainly isn't any worse after this patch.