Magnus Jacobsson [Sat, 25 Dec 2021 14:46:02 +0000 (15:46 +0100)]
common: include types.h instead of render.h in timing.c
This file does not explicitly need either of thoses files, but it
includes utils.h that needs types.h. It is better to include this file
directly rather transitively through render.h.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
As of 9550d5dae1a487617a8910b1b496ffd12c78a546, these functions are no longer
exported or needed outside of solvers.c. `solve3` has occasionally been a
hotspot for performance-constrained Graphviz use cases. So making it more
obvious to the compiler that it can inline and/or specialize `solve1` and
`solve2` may provide some speed up.
ortho: MSBuild: define GVC_EXPORTS to ensure correct storage-class attributes
The ortho lib is a static library which is linked into the
dynamic-link gvc lib and both use GVC_EXPORTS to control the
storage-class.
Removes many warnings like:
LINK : warning LNK4286: symbol '_gcalloc' defined in 'memory.obj' is imported by 'gvortho.lib(ortho.obj)' [C:\Users\magja\graphviz\lib\gvc.vcxproj]
LINK : warning LNK4217: symbol '_gcalloc' defined in 'memory.obj' is imported by 'gvortho.lib(trapezoid.obj)' in function '_construct_trapezoids' [C:\Users\magja\graphviz\lib\gvc.vcxproj]
C:\Users\magja\graphviz\lib\ortho\ortho.c(1250,1): warning C4273: 'orthoEdges': inconsistent dll linkage [C:\Users\magja\graphviz\lib\ortho\gvortho.vcxproj]
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
Magnus Jacobsson [Mon, 26 Jul 2021 12:44:47 +0000 (14:44 +0200)]
gvc: unify diverged storage-class attributes in gvc.h
More specifically, add support for the dllexport storage-class
attribute for all build systems under Windows, MinGW and Cygwin.
This will allow removing the gvc.h symbols from the gvc.def file in an
upcoming commit.
This change makes the gvc.h file conform to
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 symbol is set. An export declaration is used if the
GVC_EXPORT symbol is defined and an import declaration otherwise.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
Magnus Jacobsson [Thu, 12 Aug 2021 09:23:06 +0000 (11:23 +0200)]
gvc: add storage-class attribute declaration of gvLayoutDone in gvc.h
This function was introduced in 6f46c2c224180dc238851d2fb88d1fb909548376 which was part of a branch
which initially originated before the storage-class attributes for the
other functions in this file were introduced. This was not noted when
this branch was rebased before merge.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
graph_sgd: track number of nodes as a 'size_t' instead of 'int'
This squashes a number of compiler warnings and allows this struct to deal with
> 2³² - 1 nodes in future. Dealing with this number of nodes now is still not
possible due to locations where conversion back to `int` is necessary. In
future the source and target index arrays in this struct should probably be
converted to `size_t` too, but that was not done in this commit as it involves
more invasive changes.
LINK : warning LNK4217: symbol '_neato_init_node' defined in 'neatogen.lib(neatoinit.obj)' is imported by 'sfdp.lib(sfdpinit.obj)' in function '_sfdp_layout' [C:\Users\magja\graphviz\plugin\neato_layout\gvplugin_neato_layout.vcxproj]
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
LINK : warning LNK4217: symbol '_neato_init_node' defined in 'neatogen.lib(neatoinit.obj)' is imported by 'twopigen.lib(twopiinit.obj)' in function '_twopi_init_graph' [C:\Users\magja\graphviz\plugin\neato_layout\gvplugin_neato_layout.vcxproj]
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
LINK : warning LNK4217: symbol '_spline_edges1' defined in 'neatogen.lib(neatosplines.obj)' is imported by 'fdpgen.lib(layout.obj)' in function '_fdp_layout' [C:\Users\magja\graphviz\plugin\neato_layout\gvplugin_neato_layout.vcxproj]
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
LINK : warning LNK4217: symbol '_neato_init_node' defined in 'neatogen.lib(neatoinit.obj)' is imported by 'circogen.lib(circularinit.obj)' in function '_circo_init_graph' [C:\Users\magja\graphviz\plugin\neato_layout\gvplugin_neato_layout.vcxproj]
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
LINK : warning LNK4217: symbol '_neato_init_node' defined in 'neatogen.lib(neatoinit.obj)' is imported by 'osage.lib(osageinit.obj)' in function '_layout' [C:\Users\magja\graphviz\plugin\neato_layout\gvplugin_neato_layout.vcxproj]
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
dijkstra.c: use standard 'FLT_MAX' instead of 'MAXFLOAT'
This code is simply relying on some initial value that is “larger than any
reasonable result from the following computation.” So `FLT_MAX` is clearer and
more portable.
This function was using a static local for the index array under the assumption
that resizing an existing dynamically allocated buffer is cheaper than
allocating a new one. This is generally not true in this use case. Calling
`realloc` here was (incorrectly) telling the allocator the caller needed to
retain the prior content of the array. In other words, this was actually a
_deoptimization_. Undoing this and letting the allocator more accurately
perceive that this is a transient array allocation results in (1) more efficient
behavior and (2) less unnecessarily retained memory.
This code was relying on this value being the same as `DIST_MAX`. `DIST_MAX` is
currently set to `INT_MAX`, but using `INT_MAX` directly here implied it was
safe to change the definition of `DIST_MAX` without updating this location,
which was not true.
Magnus Jacobsson [Sat, 18 Dec 2021 07:25:59 +0000 (08:25 +0100)]
sparse: correct storage-class declaration of Verbose when STANDALONE
An upcoming commit that removes the common/globals.h symbols from the
gvc.def file would otherwise cause errors like this:
sparse.lib(mq.obj) : error LNK2001: unresolved external symbol _Verbose [C:\Users\magja\graphviz\cmd\gvmap\gvmap.vcxproj]
This is for the STANDALONE case when Verbose is defined by the
application that uses lib/sparse rather than using the definition in
lib/common/globals.h. In this case, Verbose is not exported from any
library.
From lib/sparse/general.h:
/* Applications that do not use the common library can define STANDALONE
* to get definitions/definitions that are normally provided there.
* In particular, note that Verbose is declared but undefined.
*/
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
Magnus Jacobsson [Thu, 16 Dec 2021 06:58:54 +0000 (07:58 +0100)]
gvc: remove useless exporting of intset.h symbol openIntSet from gvc.def
The openIntSet function in common/intset.h is only used in the common
and ortho libraries which are both static libraries that are built
into the gvc dynamic-link library.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
Magnus Jacobsson [Fri, 27 Aug 2021 10:03:43 +0000 (12:03 +0200)]
common: add explicit include of pathgeom.h in emit.c
emit.c explicitly uses e.g. freePath from the public pathgeom.h header
file, so even if it gets it implicitly through another header file,
including it explicitly is the right thing to do.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
neatogen: remove duplicate declaration of in_poly in neatosplines.c
The in_poly function is already declared in lib/pathplan/pathutil.h.
Without this change, an upcoming commit that adds dllimport/dllexport
storage-class attribute declarations in lib/pathplan/pathutil.h would
cause the following warning for the duplicate definition:
projects / graphviz / log