Magnus Jacobsson [Thu, 12 Aug 2021 20:08:19 +0000 (22:08 +0200)]
CMake: set GVDLL for WIN32
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.
Magnus Jacobsson [Sat, 25 Sep 2021 11:42:05 +0000 (13:42 +0200)]
common: don't use dllexport when GVDLL and _BLD_gvc are set
This is a temporary measure until an upcoming commit series cleans up
the control of the Windows storage-class attributes.
Without this change, an upcoming commit that defines GVDLL would cause
many warnings like this:
globals.obj : warning LNK4197: export 'Version' specified multiple times; using first specification [C:\Users\magja\graphviz\build\lib\gvc\gvc.vcxproj]
The reason for this is that the symbols are already defined in the
gvc.def file. For more, see
https://support.microsoft.com/en-us/topic/you-receive-an-lnk4197-error-in-the-64-bit-version-of-the-visual-c-compiler-f002b07e-4ba6-46d4-eed4-0c82412b4ac6.
Magnus Jacobsson [Tue, 21 Sep 2021 09:18:26 +0000 (11:18 +0200)]
plugin/core: include gvc/gvc.h in gvrender_core_dot.c
E.g. attach_attrs used in gvrender_core_dot.c is declared in
lib/gvc/gvc.h.
Removes this warning (from using CMake with MinGW):
C:/Users/magja/graphviz/plugin/core/gvrender_core_dot.c:469:6: warning: implicit declaration of function 'attach_attrs' [-Wimplicit-function-declaration]
Magnus Jacobsson [Tue, 21 Sep 2021 09:18:26 +0000 (11:18 +0200)]
pack: include gvc/gvc.h in ptest.c
E.g. attach_attrs used in ptest.c is declared in lib/gvc/gvc.h.
This change is not strictly necessary since gvc/gvc.h is indirectly
included through common/render.h anyway, but a direct inclusion is
clearer and will avoid confusion when an upcoming commit removes a
duplicated declaration of attach_attrs from utils.h.
Magnus Jacobsson [Tue, 21 Sep 2021 09:18:26 +0000 (11:18 +0200)]
common: include gvc/gvc.h in output.c
E.g. attach_attrs used in output.c is declared in lib/gvc/gvc.h.
This change is not strictly necessary since gvc/gvc.h is indirectly
included through common/render.h anyway, but a direct inclusion is
clearer and will avoid confusion when an upcoming commit removes a
duplicated declaration of attach_attrs from utils.h.
lefty SFcompareEntries: remove MSVC 'strcascmp' fall back
Commit 1c2c986ebb2d16e491c68656217f5352b3d809c8 replaced `SFCompareEntries`
implementation with `strcasecmp` or `_stricmp` depending on whether we were
compiling with a non-MSVC compiler or with MSVC, respectively. However, this
code is part of the X11 GUI support and hence never built with MSVC. This commit
removes this unnecessary fall back which was dead code.
lefty SFfindFile: remove MSVC 'strncasecmp' fall back
Commit 69f8a328e1d41b1cd799c715a8398ab0f096a8f4 replaced `SFstrncmp` with
`strncasecmp` or `_strnicmp` depending on whether we were compiling with a
non-MSVC compiler or with MSVC, respectively. However, this code is part of the
X11 GUI support and hence never built with MSVC. This commit removes this
unnecessary fall back which was dead code.
The clang-format style used in Graphviz is already pure LLVM style, but was
generated with clang-format-12. This means older versions of clang-format fail
because they do not understand some of the style options that were emitted by
clang-format-12. Reverting to using only `BasedOnStyle` makes it more obvious
that pure LLVM style is in use and permits older versions of clang-format to be
used. None of the newer options introduced by clang-format-12 are critical for
Graphviz formatting.
tclpathplan gt: rephrase into something more obvious
Similar to commit 1cf8e0225a6a215c93437a9972497f1cae0ffc8c. This is intended to
preserve the same semantics. It not only avoids two -Wfloat-equal warnings, but
makes this code so close to the leading comment that the comment can simply be
removed now.
fix inability to include and use gvc.h from a parent CMake project
When attempting to declare a dependency on gvc when using Graphviz as a CMake
subproject, the include path necessary to compile gvc headers would not be
propagated to dependent targets. The result would be a compilation error when
the transitive includes of gvc.h could not be found.
To validate this change, create an empty directory and add the following
CMakeLists.txt:
Clone Graphviz into the subdirectory 'graphviz'. Then the standard CMake steps:
mkdir build
cd build
cmake ..
make
Note that Graphviz dependencies and then 'bar' are correctly built.
I am not a CMake expert; this was written based on my best guess of what
Graphviz should be doing according to the CMake docs. Assuming this is correct,
other Graphviz targets probably need similar fixes.
projects / graphviz / log