osage: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes in
globals.h to be controlled only by the GVDLL symbol, not also by the
WIN32_DLL symbol.

Without this change, errors like this would occur:

osage.lib(osageinit.obj) : error LNK2001: unresolved external symbol _Ndim

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

patchwork: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes in
globals.h to be controlled only by the GVDLL symbol, not also by the
WIN32_DLL symbol.

Without this change, errors like this would occur:

patchwork.lib(patchworkinit.obj) : error LNK2001: unresolved external symbol _Ndim

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

twopigen: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes in
globals.h to be controlled only by the GVDLL symbol, not also by the
WIN32_DLL symbol.

Without this change, errors like this would occur:

twopigen.lib(twopiinit.obj) : error LNK2001: unresolved external symbol _Ndim

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

sfdp: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes in
globals.h to be controlled only by the GVDLL symbol, not also by the
WIN32_DLL symbol.

Without this change, errors like this would occur:

sfdp.lib(spring_electrical.obj) : error LNK2001: unresolved external symbol _Verbose

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

common: [nfc] rename DECLSPEC macro to GLOBALS_API in globals.h

common: [nfc] remove useless default extern declaration of functions in geomprocs.h

Merge branch 'smattr/046089E8-9134-4984-9478-E5E84A0C637F' into 'main'

CI: stop installing a custom Python on CentOS 7

See merge request graphviz/graphviz!2385

CI: stop installing a custom Python on CentOS 7

It is not clear to me why this was pulling in a custom Python 3.6 when Python
3.6 is in the default repositories on CentOS 7. It is possible it was not
packaged there at the time this Dockerfile was written.

Merge branch 'install-msys2-from-msys2.org' into 'main'

CI: install msys2 from msys2.org instead of with choco

See merge request graphviz/graphviz!2375

ci: install msys2 from msys2.org instead of with choco

Merge branch 'unify-storage-class-declarations-in-cgraph' into 'main'

Unify storage-class declarations in cgraph headers with Graphviz standard

See merge request graphviz/graphviz!2380

add a CHANGELOG entry for the breaking GVDLL change in cgraph.h

cgraph: [nfc] align storage-class declarations to Graphviz standard in sprint.h

cgraph: [nfc] rename DECLSPEC macro to SPRINT_API

cgraph: use GVDLL instead of _WIN32 to control storage-class attributes in csprint.h

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cgraph: [nfc] align storage-class declarations to Graphviz standard in cgraph.h

cgraph: use GVDLL instead of _WIN32 to control storage-class attributes in cgraph.h

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cgraph: [nfc] remove whitespace in preprocessor directives in cgraph.h

cgraph: [nfc] align storage-class declarations to Graphviz standard in cghdr.h

cgraph: [nfc] remove useless default extern declaration of functions in cghdr.h

cgraph: use GVDLL instead of _WIN32 to control storage-class attributes in cghdr.h

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cgraph: [nfc] remove whitespace in preprocessor directives in cghdr.h

cgraph: remove useless definition of _BLD_cgraph in cghdr.h

This symbol is not used anywhere.

cgraph: move include of config.h to before defining storage-class attributes in cghdr.h

The GVDLL symbol is defined in config.h for autotools builds and an
upcoming commit which changes cghdr.h to use GVDLL to control the
storage-class attribute declarations would otherwise cause errors like
this:

C:\Users\magja\graphviz\cmd\tools/gc.c:333: undefined reference to `__imp_agapply'

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cgraph: [nfc] align storage-class declarations to Graphviz standard in agxbuf.h

cgraph: [nfc] remove useless default extern declaration of functions in agxbuf.h

cgraph: use GVDLL instead of _WIN32 to control storage-class attributes in agxbuf.h

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cgraph: [nfc] remove whitespace in preprocessor directives in agxbuf.h

cgraph: include config.h in agxbuf.h to get GVDLL in autotools builds

An upcoming commit which changes agxbuf.h to use GVDLL to control the
storage-class attribute declarations would otherwise cause errors like
this:

C:\Users\magja\graphviz\lib\gvc/gvplugin.c:386: undefined reference to `__imp_agxbprint'

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cgraph++: use GVDLL instead of _WIN32 to control storage-class attributes in AGraph.h

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cgraph++: [nfc] align storage-class declarations to Graphviz standard in AGraph.h

tests: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cgraph.h.

Without this change, errors like this would occur when building the
test examples:

demo.obj : error LNK2019: unresolved external symbol Agdirected referenced in function main

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

lib/gvpr: use GVDLL instead of _WIN32 to control gprDisc init in compile.c

Without this change, an upcoming commit that changes cgraph.h to use
GVDLL instead of _WIN32 to control storage-class attributes would
cause this error:

compile.c:85:29: error: initializer element is not constant
   85 | static Agdisc_t gprDisc = { &AgMemDisc, &AgIdDisc, &gprIoDisc };
      |                             ^
compile.c:85:29: note: (near initialization for ‘gprDisc.mem’)

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

dot: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cgraph.h.

Without this change, errors like this would occur:

dot.obj : error LNK2001: unresolved external symbol _Agdirected

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

sccmap: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cgraph.h.

Without this change, errors like this would occur:

sccmap.obj : error LNK2001: unresolved external symbol _Agdirected

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

bcomps: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cgraph.h.

Without this change, errors like this would occur:

bcomps.obj : error LNK2001: unresolved external symbol _Agstrictundirected

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

mm2gv: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cgraph.h.

Without this change, errors like this would occur:

mm2gv.obj : error LNK2001: unresolved external symbol _Agdirected

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

ccomps: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cgraph.h.

Without this change, errors like this would occur:

ccomps.obj : error LNK2001: unresolved external symbol _Agstrictundirected

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

dotgen: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cgraph.h.

Without this change, errors like this would occur:

dotgen.lib(mincross.obj) : error LNK2001: unresolved external symbol _Agstrictdirected

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

Start 3.0 development series

An upcoming commit will introduce a breaking change.

Merge branch 'smattr/18156802-8e89-4532-9958-fdc6fb4c0f13' into 'main'

convert lib/mingle/ink.c to C++

See merge request graphviz/graphviz!2381

lib/mingle: remove an unused sparse include

lib/mingle: replace some 'MIN' usage with 'std::min'

lib/mingle ink: pass point lists around as vectors instead of C arrays

lib/mingle ink: avoid manual memory management of 'targets'

lib/mingle: scope use of an array to a local temp

Similar to the preceding changes for `sources`, it is not clear to me why this
code was using the `targets` array when the output values are irrelevant.

lib/mingle ink: avoid manual memory management of 'sources'

lib/mingle: scope use of an array to a local temp

It is not clear to me why this loop was using the `sources` array. AFAICT the
values written to this array are (1) not used by subsequent loop iterations (no
loop-carried dependency) and (2) not used after the loop before being
overwritten by other values.

This change cuts the dependency. A future commit will refactor the allocation in
this area to avoid allocating a possibly-unused array upfront.

lib/mingle: rephrase some open coded hypotenuse calculations

Surprisingly every `sqrt` call in this file except one is a hypotenuse
calculation that can be done more accurately. Maybe `hypot` was not widely
available when this code was written.

lib/mingle: replace some 'MAX' usage with 'std::max'

This is straightforward find-and-replace. No attempt was made to investigate if
the surrounding algorithm could/should be rephrased.

Gitlab: #2154

lib/mingle: [nfc] change C includes to their C++ equivalents

lib/mingle: move ink.c into C++

lib/mingle already has a C++ source, requiring it to link against the C++
standard library. There is no advantage to keeping some of its sources in C.

This does nothing fancy, just rename the existing file. All contained code looks
compatible across C and C++. Future commits will refactor this to more modern
C++ style.

Gitlab: #2154

lib/mingle: [nfc] pre-emptively squash -fpermissive warning

When moving this code to C++ in an upcoming commit, this would otherwise
trigger:

  lib/mingle/ink.cpp:46:22: error: uninitialized const 'Origin' [-fpermissive]
   static const point_t Origin;
                        ^
  In file included from lib/mingle/ink.cpp:17:0:
  lib/mingle/ink.h:19:16: note: 'const struct point_t' has no user-provided
    default constructor
   typedef struct {
                  ^
  lib/mingle/ink.h:20:10: note: and the implicitly-defined constructor does not
    initialize 'double point_t::x'
     double x, y;
          ^

This noisy initialization can probably be undone after mingle and libmingle are
moved to entirely C++.

Gitlab: #2154

lib/mingle: [nfc] remove an unused include

Merge branch 'fix-parallel-visual-studio-builds' into 'main'

Fix parallel Visual Studio builds

See merge request graphviz/graphviz!2377

add a changelog entry for Visual Studio fix

https://gitlab.com/graphviz/graphviz/-/issues/2175.

twopigen: MSBuild: add project reference to version

Closes https://gitlab.com/graphviz/graphviz/-/issues/2175.

circogen: MSBuild: add project reference to version

Towards https://gitlab.com/graphviz/graphviz/-/issues/2175.

ortho: MSBuild: add project reference to version

Towards https://gitlab.com/graphviz/graphviz/-/issues/2175.

fdpgen: MSBuild: add project reference to version

Towards https://gitlab.com/graphviz/graphviz/-/issues/2175.

patchwork: MSBuild: add project reference to version

Towards https://gitlab.com/graphviz/graphviz/-/issues/2175.

gv2gml: MSBuild: add project reference to gvc

Towards https://gitlab.com/graphviz/graphviz/-/issues/2175.

Merge branch 'smattr/a679a524-8d3d-45b7-8da2-729372854b24' into 'main'

remove reused buffer in spline routing

See merge request graphviz/graphviz!2359

remove reused buffer in spline routing

Code in routespl.c used a long-lived buffer, `ps`, that it resized to deal with
various operations. This made the code thread-unsafe, and note that there are
also various work arounds in routespl.c to deal with re-entrancy which is
complicated by this design.

This commit rephrases `simpleSplineRoute` and `_routesplines` to dynamically
allocate a fresh buffer for each operation. The ergonomics cost of this is that
callers of `simpleSplineRoute`, `routesplines`, and `routepolylines` now need to
eventually free the returned pointer. This is unfortunately fairly noisy to deal
with in C and would have been cleaner in C++.

In future, this direction should probably be taken further to allow
`routesplinesinit` and `routesplinesterm` to be removed. This design that relies
on static globals is incompatible with multi-threading, so if Graphviz ever
wants to support multi-threading, this will need to be removed.

Note that this commit introduce two new warnings (for the `calloc` calls with
`int` values). The cost seems worth it and hopefully these warnings can be
removed in future.

This change has a performance impact. For smaller graphs, this likely slightly
degrades performance due to repeated small allocations that previously would not
have been required. For larger graphs, this perhaps improves performance as the
allocator no longer (spuriously) believes it needs to retain the contents of
`ps` across calls.

Merge branch 'smattr/3e7bbb62-f0eb-49c3-8fc3-e02f3948ea62' into 'main'

more boolean → bool modernization

See merge request graphviz/graphviz!2369

poly_gencode: remove claim that 'filled' is a boolean

This variable is not treated as a boolean within this function. Declaring it as
a boolean appears to have been a mistake and only worked out coincidentally as
all set values fit within the `boolean` type.

handle_keypress: return a C99 bool instead of a boolean

getdoubles2ptf: return a C99 bool instead of boolean

glitz_finalize: use a C99 bool for 'watching_p' instead of a boolean

gdgen_begin_page: use a C99 bool for 'truecolor_p' instead of a boolean

pccomps: use a C99 bool for 'pin' instead of a boolean

stress_majorization_cola: use a C99 for 'converged' instead of a boolean

gvplugin_list: use a C99 bool for 'new' instead of boolean

use C99 bools for 'isVert' members instead of booleans

generateNonoverlapConstraints: take a C99 bool instead of boolean

Note that this required propagating this change through to `genXConstraints` as
well.

spline_edges0: take a C99 bool instead of a boolean

makeSpline: take a C99 bool instead of a boolean

Merge branch 'unify-storage-class-declarations-in-cdt' into 'main'

Unify storage-class declarations in cdt.h with Graphviz standard

See merge request graphviz/graphviz!2378

cdt: [nfc] align storage-class declarations to Graphviz standard in cdt.h

cdt: use GVDLL instead of _WIN32 to control storage-class attributes in cdt.h

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cdt: [nfc] remove whitespace in preprocessor directives in cdt.h

cdt: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, the following error would occur:

LINK : fatal error LNK1104: cannot open file 'C:\GitLab-Runner\builds\magjac\graphviz\Debug\Graphviz\bin\cdt.lib' [C:\GitLab-Runner\builds\magjac\graphviz\lib\pathplan\Pathplan.vcxproj]

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

gvpack: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

gvpack.obj : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

graphml2gv: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

graphml2gv.obj : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

gxl2gv: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

gxl2gv.obj : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

dijkstra: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

dijkstra.obj : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

gml2gv: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

gv2gxl.obj : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

plugin/core: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

gvrender_core_json.obj : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

fdpgen: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

fdpgen.lib(grid.obj) : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

circogen: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

circogen.lib(edgelist.obj) : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

neatogen: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

neatogen.lib(neatosplines.obj) : error LNK2001: unresolved external symbol _Dtoset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

expr: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

expr.lib(y.tab.obj) : error LNK2001: unresolved external symbol _Dtset

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

cgraph: MSBuild: define GVDLL to ensure correct storage-class attributes

An upcoming commit will change the storage-class attributes to be
controlled by the GVDLL symbol in cdt.h.

Without this change, errors like this would occur:

refstr.obj : error LNK2001: unresolved external symbol _Dttree [C:\GitLab-Runner\builds\magjac\graphviz\lib\cgraph\cgraph.vcxproj]

Towards https://gitlab.com/graphviz/graphviz/-/issues/2173.

Merge branch 'post-remove-gvc-def-file-cleanup' into 'main'

Some cleanup of duplicate declarations

See merge request graphviz/graphviz!2379

plugin/gd: remove duplicate definition of Bezier in gvrender_gd_vrml.c

Removes this warning:

C:\Users\magja\graphviz\plugin\gd\gvrender_gd_vrml.c(41,86): warning C4273: 'Bezier': inconsistent dll linkage [C:\Users\magja\graphviz\plugin\gd\gvplugin_gd.vcxproj]

plugin/gd: remove duplicate declaration of shapeOf in plugin/gd/gvrender_gd_vrml.c

sparse: replace local declaration of colorxlate with including common/colorprocs.h in colorutil.h

sparse: MSBuild: add windows include dir to find config.h

An upcoming commit which will include config.h in colorprocs.h would
otherwise cause this error:

C:\Users\magja\graphviz\lib\common\colorprocs.h(13,10): fatal error C1083: Cannot open include file: 'config.h': No such file or directory [C:\Users\magja\graphviz\lib\sparse\gvsparse.vcxproj]

dot: unconditionally include globals.h in dot.c instead of duplicating declarations for WIN32_DLL

Merge branch 'remove-gvc-def-file' into 'main'

Remove the last symbols from gvc.def and remove the gvc.def file

Closes #2058

See merge request graphviz/graphviz!2376