Merge branch 'fix-mingw-cmake-builds-and-add-tests' into 'main'

Fix MinGW CMake builds and add tests

Closes #2176 and #1780

See merge request graphviz/graphviz!2387

ci: add windows-mingw32-cmake-test job

ci: add windows-mingw64-cmake-test job

add ci/mingw-test.sh

ci/mingw-install.sh: install python-pip

test_1408: don't expect failure on MinGW

It's unclear why this test does not fail on MinGW when if fails on
other OSes. The NDEBUG symbols is not defined in MinGW builds and
assertions have been verified to be enabled.

gvtest.py: correct compiler used on MinGW

CMake: ensure PangoCairo is found on MinGW

This makes the PNG format available in CMake builds with MinGW.

CMake: ensure Cairo is found on MinGW

plugin/pango: print font map when verbose for all platforms

This effectively reverts commit
2029d4bf76360aba04a0ca779058caba7682e1e9.

Fixes this error with CMake on MinGW when compiled with -Werror:

C:/Users/magja/graphviz/plugin/pango/gvgetfontlist_pango.c:477:1: error: 'printFontMap' defined but not used [-Werror=unused-function]
  477 | printFontMap (gv_font_map*gv_fmap, int sz)
      | ^~~~~~~~~~~~

plugin/pango: include common/globals.h in gvgetfontlist_pango.c

An upcoming commit which enables code that uses the Verbose global
variable would otherwise cause this error:

gvgetfontlist_pango.obj : error LNK2019: unresolved external symbol _Verbose referenced in function _get_font_mapping [C:\GitLab-Runner\builds\magjac\graphviz\build\plugin\pango\gvplugin_pango.vcxproj]
C:\GitLab-Runner\builds\magjac\graphviz\build\plugin\pango\Release\gvplugin_pango.dll : fatal error LNK1120: 1 unresolved externals [C:\GitLab-Runner\builds\magjac\graphviz\build\plugin\pango\gvplugin_pango.vcxproj]

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

An upcoming commit which enables code that uses the Verbose global
variable would otherwise cause this error:

gvgetfontlist_pango.obj : error LNK2001: unresolved external symbol _Verbose

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

gvpr: correct fix for absolute paths to work also on MinGW

Fixes https://gitlab.com/graphviz/graphviz/-/issues/1780 on MinGW.

Without this fix, test_1780 fails:

__________________________________ test_1780 __________________________________
Traceback (most recent call last):
  File "C:/Users/magja/graphviz2/rtest/test_regression.py", line 594, in test_1780
    subprocess.check_call(["gvpr", "-f", clustg], stdin=subprocess.DEVNULL)
  File "C:/tools/msys64/mingw64/lib/python3.9/subprocess.py", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['gvpr', '-f', WindowsPath('C:/Users/magja/graphviz2/cmd/gvpr/lib/clustg')]' returned non-zero exit status 4294967295.
---------------------------- Captured stderr call -----------------------------
gvpr: gvpr
Usage: gvpr gvpr

plugin/pango: work around CMake not generating DLLs with version numbers on MinGW

Fixes https://gitlab.com/graphviz/graphviz/-/issues/2176.

plugin/neato_layout: work around CMake not generating DLLs with version numbers on MinGW

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

plugin/gdiplus: work around CMake not generating DLLs with version numbers on MinGW

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

plugin/gd: work around CMake not generating DLLs with version numbers on MinGW

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

plugin/dot_layout: work around CMake not generating DLLs with version numbers on MinGW

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

plugin/core: work around CMake not generating DLLs with version numbers on MinGW

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

CMake: detect "dot -c" failure when running cpack

This reveals this error when "dot -c" is executed when running cpack
on MinGW:

CPack: Create package using ZIP
CPack: Install projects
CPack: - Install project: Graphviz []
CMake Error at C:/Users/magja/graphviz2/cmake/configure_plugins.cmake:38 (execute_process):
  execute_process abnormal exit: Access violation
Call Stack (most recent call first):
  C:/Users/magja/graphviz2/build/cmd/dot/cmake_install.cmake:91 (include)
  C:/Users/magja/graphviz2/build/cmd/cmake_install.cmake:42 (include)
  C:/Users/magja/graphviz2/build/cmake_install.cmake:60 (include)

CPack Error: Error when generating package: Graphviz

See https://gitlab.com/graphviz/graphviz/-/issues/2176.

Merge branch 'smattr/B7A7E3A2-8D16-48E6-A2EE-1E56CD300DF2' into 'main'

delete unused header constants

See merge request graphviz/graphviz!2382

API BREAK: remove unused '_DUMMY_ELEM'

ISO C99 and C++11 both permit trailing commas in enum members. Graphviz has been
compiled using C99 since fe3f9411d2c59b463ab1b64eecfd19f2db55d2fc and C++11
since a74e0e104e114bcf890eb8419a0bf02a22e01d84. This wart was not removed
previously as removing it was considered an API break not worth doing. The
upcoming release is projected to bump the major version number, making breaks
like this more acceptable.

API BREAK: remove unused 'MAXSHORT' definition

The last use of this was removed in 580fa88477fa59aca01e405c986c686ceee21b5f.
But its definition was retained in this header as removing it was considered an
API break not worth causing. The upcoming release is projected to bump the major
version number, so we can now remove it.

API BREAK: remove local 'INT_MAX' and 'INT_MIN' definitions

These constants are defined in ISO C to be available in limits.h, but were
commonly available pre-ISO C too. These definitions remained here for legacy
reasons, because removing them was considered an API break and not worth doing
for this minor clean up. However the upcoming release is projected to involve a
major version number bump.

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

Unify storage-class declarations in common headers with Graphviz standard

See merge request graphviz/graphviz!2386

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

plugin/visio: use only the GVDLL symbol enable storage-class attributes in gvplugin_visio.c

Anything that depends on storage-class attributes already define both
GVC_EXPORTS and WIN32_DLL.

MSBuild: remove now obsolete definition of WIN32_DLL from all project files

pack: autotools: remove now obsolete definition of _BLD_gvc

pack: CMake: remove now obsolete definition of _BLD_gvc

ortho: autotools: remove now obsolete definition of _BLD_gvc

ortho: CMake: remove now obsolete definition of _BLD_gvc

gvc: autotools: remove now obsolete definition of _BLD_gvc

gvc: CMake: remove now obsolete definition of _BLD_gvc

common: autotools: remove now obsolete definition of _BLD_gvc

common: CMake: remove now obsolete definition of _BLD_gvc

gvc: remove useless definition of _BLD_gvc in gvusershape.c

This symbols is already defined by all build systems that depend on
it.

common: use only GVC_EXPORTS to control storage-class attributes in global.h

Anything that depends on storage-class attributes already define both
GVC_EXPORTS and _BLD_gvc.

common: use only the GVDLL symbol enable storage-class attributes in global.h

Anything that depends on storage-class attributes already define both
GVC_EXPORTS and WIN32_DLL.

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.