This is a first step to moving away from PowerShell for CI scripts. PowerShell
has too many error prone characteristics and there is not enough knowledge about
it amongst the Graphviz maintainers.
Pylint has a very narrow idea of acceptable names. Things it does not like, such
as single letter variable names, are not really a problem in the Graphviz
scripts.
disable f-string in logging messages Pylint warning
This is generally considered error prone because you can include non-pure
operations in logging functions that your code accidentally depends on. However
the Graphviz scripts are simple enough that this is not a significant issue. The
use of f-strings pervasively makes for more consistent and readable scripts.
Remove the singular reference to `_BLD_stdio`. This is part of a series
to remove unused build macros to unify on the CMake standard `*_EXPORTS`
macros.
edgepaint: fix type of variable for interacting with getopt
Similar to 49fd8f62d8103d6e40a33922d2492a5ec3e3e76e, this location was using an
unsigned int for some reason. This change squashes a -Wsign-compare and a
-Wsign-conversion warning.
add a test case to keep .vcxproj and .vcxproj.filters sources in sync
Inspired by reviewing !1925, I realized there are few safeguards for those of us
editing the .vcxproj files while not on Windows. This commit introduces a basic
seatbelt to try to keep these files in sync. In future we could extend this to
check for file existence and other consistency.
This header is unused and does not need to be included. Although for
most uses this does not impact anything, attempting to use this in a
Swift program causes problems due to the library being pulled into a
modular build. This removal allows the use of xdot in Swift.
With the prior couple of changes, neither the Windows build nor the test suite
relies on a python3.exe binary. So we can simplify Windows CI by removing these
steps, leaving only a python.exe binary. This is more reflective of the typical
environment a user will have too. Related to #2049.
call Python as `python` instead of `python3` in MSBuild files
This removes an assumption from these files that Python 3 is available as
`python3`. On a Windows system, it is typically python.exe and users have to
create their own python3.exe if they want to call it under this name. Related to
#2049.
use CMake support to locate Python 3 before calling it
This change means (1) the CMake build system will fail less cryptically when
Python 3 is unavailable and (2) the CMake build system is now able to locate and
use Python 3 even when it is not called `python3`. Related to #2049.
remove test suite assumption that Python can be run as `python3`
On Windows, python3.exe does not typically exist. The python.exe binary is
Python 3 and is intended to be called as just this. The CI setup currently works
around this by copying python.exe to python3.exe. This change removes any
dependency on python3 existing, which should ease life for both CI and Windows
users wanting to run the test suite. Closes #2049.
build: use CMake to drive the position independence
This replaces the use of `-fPIC` with `CMAKE_POSITION_INDEPENDENT_CODE`
which is used by CMake to initialise the `POSITION_INDEPENDENT_CODE`
property on targets, which allows the portable way to indicate the
compiler-independent spelling for `-fPIC`. This was previously unset on
MSVC because MSVC does not support the `-fPIC` option and Windows by
default is PIC by means of the base relocation of the binary.
What kind of a warning is this? A class with even a single method isn’t a
mistake. It’s likely abstraction or indicating something semantic to the reader.
The function sprintf is generally considered unsafe to use in modern C. In the
Graphviz code base, its uses are slowly being replaced with safer alternatives
(#1950). However, the alternative code is frequently overly verbose and
counter-intuitive. This commit adds (hopefully) convenient alternative functions
that can be used to replace sprintf uses. The gv_sprint function is similar to
the GNU asprintf function with a different calling convention.
The tests added alongside follow the same strategy as used for testing
lib/vmalloc.
There is no need to defer this to runtime. Making this a compile-time constant
allows the compiler to constant-fold computations involving it, producing more
efficient code.
Note, this is not really even the correct notion of platform alignment. The
alignment of a type is not guaranteed to be the same as its size. Nevertheless,
we leave this alone for now.
fix: consistently treat entry indices as uint64_t in tclhandle
This code intermingled uint64_t and int values for representing indices into an
array. Making this consistent removes a huge number of -Wsign-conversion and
-Wsign-compare compiler warnings, as well as more serious problem where printing
code assumed "%lu" was the format code to print an index. This is not true when
uint64_t is not the same type as unsigned long and would have most probably
resulted in stack corruption.