There was the option to remove the first duplicate or the second in this file. I
checked that none of the intervening includes depended on a `_BB` definition. It
seemed clearer to remove the first and indicate that only Smyrna itself is using
`_BB`.
toggle Lefty to disabled by default in the Autotools build system
Based on a discussion that Lefty should be deprecated,¹ this takes the first
step towards removing it. It is hoped that by disabling it by default, this will
expose any downstream consumers who are relying on it being built by default.
If there are no complaints within three months, I think we can then remove build
system support entirely. If another three months pass without noise, I think we
can then remove Lefty sources from Graphviz.
In case the linked discussion is inaccessible when reading this commit message,
the summary from Stephen was:
Lefty was an early interpreter for graphics programming. It’s from about 1990
or 91, and we used it as the basis for a scriptable graphviz viewer, dotty.
It was student code written by Lefteris Koutsofios. I thought there was some
C code for parsing graphs but I could be wrong.
Even libast came into the picture much later, but I suppose that was done to
clean up some of its OS dependencies or to make it more portable or robust in
some way.
Magnus Jacobsson [Tue, 14 Sep 2021 14:27:04 +0000 (16:27 +0200)]
common: unify diverged storage-class attributes in globals.h
The immediate reason for this commit is to fix a bug when using the
autools build system with Cygwin, described below, but it is also a
step towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545.
This file had one set of Windows-specific storage-class attribute
declarations intended for use with the autotools build system and one
set intended for use with Visual Studio, with slightly different
control mechanisms.
It's unclear what effect changes made to these control mechanisms over
the years has had on the many operating systems that are not tested in
CI. The current state is that they partly overlap and are very hard to
understand.
This commit cleans this up by applying such declarations only if the
GVDLL or the WIN32_DLL symbol is set. An export declaration is used if
either the GVC_EXPORT or the _BLD_GVC symbol is defined and an import
declaration otherwise.
Using both GVDLL and WIN32_DLL for the same purpose is a temporary
measure and will be replaced by only one symbol in an upcoming commit
series towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545.
Since https://gitlab.com/graphviz/graphviz/-/merge_requests/2182,
setting GVDLL is the preferred single mechanism to enable those
attributes, rather than using _WIN32 and __CYGWIN__ plus some other
symbol to distinguish between static and dynamic-link/shared
libraries.
Likewise is the use of both GVC_EXPORT and _BLD_gvc for the same
purpose a temporary measure, which will be replaced by only one symbol
in an upcoming commit series towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545.
This fixes a segmentation fault when running 'dot -c' during 'make install' on Cygwin.
Debugging with gdb showed that this happened on line 99 in dot.c:
GvExitOnUsage = 1;
Magnus Jacobsson [Tue, 14 Sep 2021 18:06:19 +0000 (20:06 +0200)]
cmd/edgepaint: MSBuild: define GVDLL in the project file
Without this change, an upcoming commit in this series that unites the
storage class attributes in lib/common/globals.h that have diverged
for different build systems, would cause edgepaint to generate a
segmentation fault (error code 3221225477 = 0xC0000005: access
violation) when started on native Windows.
Also towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545.
Magnus Jacobsson [Mon, 13 Sep 2021 15:11:21 +0000 (17:11 +0200)]
gvc: autotools: work around cygwin linking problem with .def file
This workaround is just a temporary measure until an upcoming commit
series towards https://gitlab.com/graphviz/graphviz/-/issues/2058 will
remove the .def file.
Fixes this error with Cygwin when running 'dot -c' during installation.
C:/Users/magja/graphviz/build/bin/dot.exe: error while loading shared libraries: gvc.dll: cannot open shared object file: No such file or directory
Before this commit, the following results were obtained:
Magnus Jacobsson [Sat, 11 Sep 2021 10:30:06 +0000 (12:30 +0200)]
cmd/dot: autotools: cd to bin dir before running dot -c
Fixes this error with Cygwin:
C:/GitLab-Runner/builds/magjac/graphviz/build/bin/dot.exe: error while loading shared libraries: cygcgraph-6.dll: cannot open shared object file: No such file or directory
Magnus Jacobsson [Sun, 22 Aug 2021 06:40:28 +0000 (08:40 +0200)]
ortho: autotools: set also GVC_EXPORTS
The immediate reason for this change is to correct the
Microsoft-specfic storage-class attributes in autotools builds with
Cygwin.
The object modules from the static ortho lib is statically linked into
the gvc shared lib which means that its symbols should be exported
from gvc instead of imported.
This is the second and final step in fixing these errors in autotools
builds with Cygwin:
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: ../../lib/dotgen/.libs/libdotgen_C.a(dotsplines.o): in function `_dot_splines':
/home/magja/graphviz/lib/dotgen/dotsplines.c:334: undefined reference to `__imp_orthoEdges'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: /home/magja/graphviz/lib/dotgen/dotsplines.c:337: undefined reference to `__imp_orthoEdges'
The _BLD_gvc symbol is used for basically the same purpose as
GVC_EXPORTS. Using both is a temporary measure until an upcoming
commit series towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545
cleans up the control of the Windows specific storage-class attributes
Magnus Jacobsson [Sun, 22 Aug 2021 08:45:11 +0000 (10:45 +0200)]
ortho: use GVDLL instead of _WIN32 to enable storage-class attributes
The immediate reason for this change is to enable Windows-specific
storage-class attributes for autotools builds with Cygwin. The _WIN32
symbol is not defined when using Cygwin.
Since https://gitlab.com/graphviz/graphviz/-/merge_requests/2182,
setting GVDLL is the preferred single mechanism to enable those
attributes, rather than using _WIN32 and __CYGWIN__ plus some other
symbol to distinguish between static and dynamic-link/shared
libraries.
This is the first step of two in fixing these errors in autotools
builds with Cygwin:
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: ../../lib/dotgen/.libs/libdotgen_C.a(dotsplines.o): in function `_dot_splines':
/home/magja/graphviz/lib/dotgen/dotsplines.c:334: undefined reference to `orthoEdges'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: /home/magja/graphviz/lib/dotgen/dotsplines.c:337: undefined reference to `orthoEdges'
The Windows-specific storage-class attributes are however still not
correct for Cygwin autotools builds, since GVC_EXPORT is currently not
set in the autotools builds. The error is now instead:
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: ../../lib/dotgen/.libs/libdotgen_C.a(dotsplines.o): in function `_dot_splines':
/home/magja/graphviz/lib/dotgen/dotsplines.c:334: undefined reference to `__imp_orthoEdges'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: /home/magja/graphviz/lib/dotgen/dotsplines.c:337: undefined reference to `__imp_orthoEdges'
The next commit in this series will fix this.
Also towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545
Without this change, an upcoming commit in this series that will use
GVDLL instead of _WIN32 to enable Microsoft-specific storage-class
attributes would cause this error:
neatogen.lib(neatosplines.obj) : error LNK2019: unresolved external symbol _orthoEdges referenced in function __spline_edges [C:\GitLab-Runner\builds\magjac\graphviz\plugin\neato_layout\gvplugin_neato_layout.vcxproj]
Since https://gitlab.com/graphviz/graphviz/-/merge_requests/2182,
setting GVDLL is the preferred single mechanism to enable
Microsoft-specific storage-class attributes.
Also towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545
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.
projects / graphviz / log