The GVDLL symbol has for a long time been used by the autotools build
system to control whether to apply the Microsoft storage-class
attributes, __declspec(dllexport) and __declspec(dllimport), that are
needed when building dynamic-link libraries (DLLs) on Windows, also
when using MinGW. The autotools build system does not define GVDLL
when static linking is requested.
Since the introduction of the CMake build system, this functionality
has gradually become more and more broken for both dynamic-link
libraries with MinGW and for static libraries in general under
Windows.
Upcoming commit series will try to restore this functionality. Rather
than having a plethora of different symbols controlling the
storage-class attributes in different ways for different build
systems, they will settle on something like this across all build
systems:
This means that in order to continue to support dynamic-link libraries
with CMake, the GVDLL symbol must be set.
The CMake build system does not currently support building static
libraries, so the GVDLL symbol can be unconditionally set for WIN32
until such support is introduced.
This is also a very small step towards
https://gitlab.com/graphviz/graphviz/-/issues/2058.
option(with_cxx_tests "enables building the C++ tests" OFF)
option(use_win_pre_inst_libs "enables building using pre-installed Windows libraries" ON)
+if (WIN32)
+ # Build dynamic-link libraries on Windows, including MinGW. The
+ # CMake build system does not currently support building static
+ # libraries, so the GVDLL symbol can be unconditionally set until
+ # such support is introduced.
+ add_definitions(-DGVDLL)
+endif()
+
if (with_digcola)
add_definitions(-DDIGCOLA)
endif (with_digcola)