cmd/mingle depends on lib/mingle, which in turn depends on libANN, a C++
library. Thus the `mingle` binary needs to link against the C++ standard
library. There is no advantage to Mingle being implemented in C, and some nice
advantages to it being implemented in C++ instead.
This commit does a basic rename, as AFAICT nothing in minglemain.c has varying
semantics between C and C++. Future commits will use C++ features to simplify
the code.
This has no effect at present. However, when moving this code to C++ in an
upcoming commit, it would trigger -fpermissive problems. This change
pre-emptively prevents this issue.
mingle: cast 'name' parameter values in 'agattr' calls
This has no effect at present. However, when moving this code to C++ in an
upcoming commit, it would trigger -Wwrite-strings warnings. This change
pre-emptively prevents these warnings.
This makes the intent of the code slightly clearer, but also pre-emptively
avoids an upcoming -Wwrite-strings warning when converting this code to C++.
The functions removed in this commit were intended to be aliases for the
same-named macros declared in cgraph.h. The claimed purpose is debugger
introspection.
It is unclear to me what value these have in a modern development environment.
Some modern debuggers can understand macro definitions. Those that cannot are
_impeded_ by these aliases. A developer debugging looks at the alias definition
and thinks they understand the code, but they do not. The code that is executing
on their system is _not_ the code these functions compile to. To state something
stronger: it is unclear to me how these definitions were ever helpful. They
appear to (accidentally) obscure what is actually occurring in the machine at
runtime.
Note that these functions also bloated the cgraph .so/.a size by including
functions that were never called.
These functions were introduced in c9b7b0719776e022d760195fae2727b84be82eda to
match `AGMKOUT` and `AGMKIN` (#1212). But there are no exposed prototypes for
these. So the only way to call them is to externally prototype them with a
best-guess type signature and hope Graphviz never changes. This commit removes
them to reduce portability problems.
libANN is now installed in all Red Hat environments in CI (CentOS and Fedora)
and building Mingle is enabled in all. So we remove this configuration flag that
is no longer used.
Magnus Jacobsson [Sat, 11 Dec 2021 14:57:39 +0000 (15:57 +0100)]
common: include config.h in colorprocs.h to get GVDLL in autotools builds
An upcoming commit that corrects the storage-class attribute
declarations in colorprocs.h would otherwise cause this error:
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: ../../lib/sparse/.libs/libsparse_C.a(DotIO.o): in function `Import_coord_clusters_from_dot':
/home/magja/graphviz/lib/sparse/DotIO.c:577: undefined reference to `colorxlate'
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
sgd_graph: use 'size_t' for 'sources' and 'targets'
Following on from 1c42bb82cd73cb45d3abee845c21819add00d982, this uses a more
appropriate type for these members, permitting collections that exceed 2³² - 1
and avoiding sign conversion issues.
prototype osage_layout and osage_cleanup in osage.h
These are the only functions lib/osage exports. Yet neither were prototyped in a
header. It seems like this header could now be #included in
plugin/neato_layout/gvlayout_neato_layout.c, removing the need for that file to
prototype these functions. Except that it gives slightly different prototypes
for them.
Commit 1a4ad00b59cc1e1e9302fcbd1a205495ee59cab5 disabled Lefty by default in the
Autotools build system but accidentally made the configure output say nothing
next to "Lefty: " when Lefty is disabled.
tred: autotools: link to the shared gvc lib instead of the static common lib
The common lib is built into the gvc lib.
An upcoming commit that changes tred.c to include utils.h instead of
timing.h would otherwise cause these errors:
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: tred.o: in function `process':
/cygdrive/c/GitLab-Runner/builds/magjac/graphviz/cmd/tools/tred.c:296: undefined reference to `__imp_start_timer'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /cygdrive/c/GitLab-Runner/builds/magjac/graphviz/cmd/tools/tred.c:299: undefined reference to `__imp_elapsed_sec'
Magnus Jacobsson [Sat, 25 Dec 2021 14:50:26 +0000 (15:50 +0100)]
common: include utils.h and types.h in timing.c also for _WIN32
This ensures that the timing functions are declared with the
storage-class attributes from utils.h.
An upcoming commit that corrects the storage-class attribute
declarations in utils.h would otherwise cause these errors:
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: ../../lib/dotgen/.libs/libdotgen_C.a(mincross.o): in function `init_mincross':
/home/magja/graphviz/lib/dotgen/mincross.c:1163: undefined reference to `__imp_start_timer'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: ../../lib/dotgen/.libs/libdotgen_C.a(mincross.o): in function `cleanup2':
/home/magja/graphviz/lib/dotgen/mincross.c:996: undefined reference to `__imp_elapsed_sec'
The reason for also including types.h is that utils.h depends on it
without including it itself for unclear reasons.
Note that these functions are also redundantly declared in
timing.h. This file will be removed in an upcoming commit series.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2058.
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.
projects / graphviz / log