As of fe3f9411d2c59b463ab1b64eecfd19f2db55d2fc, Graphviz requires a C99
compiler. C99 guarantees `sqrtf` so even if the “bug” discussed in the original
commit still exists, generating a `sqrtf` call is fine on a C99 toolchain.
work around a bug in GCC: It generates a call to "sqrtf" for "(float)sqrt(d)"
but sqrtf doesn't exist in libm.a.
reported by: Aaron Digulla <digulla@hepe.com>
As of fe3f9411d2c59b463ab1b64eecfd19f2db55d2fc, Graphviz requires a C99
compiler. C99 guarantees `sqrtf` so even if this “bug” still exists, generating
a `sqrtf` call is fine on a C99 toolchain.
CMake: detect and enable extra optional GD features with gdlib-config
This replicates some logic from the Autotools build system, enabling output
formats like `png:gd`. Note that this only enables `png:gd` on CentOS because
other packaging ecosystems do not seem to include `gdlib-config`.
In retrospect, this test case does not make sense in the regular test suite. It
is validating a particular plugin feature is enabled. It is perfectly valid to
build a version of Graphviz without png:gd support, yet it will fail this test
case.
neatogen: replace 'MAXFLOAT' in clamping logic with 'FLT_MAX'
This seems a more accurate definition of what overflow would mean under C99.
Though as far as I can tell, it is not possible to reach this code with negative
values in the array, so the `< 0` check is always false. The `>= FLT_MAX` is
true for both `FLT_MAX` itself as well as positive infinity.
Jobs inheriting from this template were attempting to set `$OS_ID` from the file
OS_ID that did not exist before `install-package.sh` was run. The result was
output in the build log like:
export OS_ID=$( cat OS_ID )
cat: OS_ID: No such file or directory
Somewhat surprisingly, tests were still passing. The reason is that `$OS_ID` is
only accessed in ci/tests.py and on Ubuntu (the platform used for both ctest
jobs) the only `$OS_ID`-based skip is for `mingle`, that is also coincidentally
skipped due to these jobs using the CMake build system where `mingle` is not
build. That is, the mingle check is meant to be skipped on lines 104-108, but
actually ends up skipped on lines 116-122 due to `$OS_ID` being empty.
In future, all of this should be refactored to use a less brittle technique for
asking “what distro are we running on?” When moving to Python 3.10,
`platform.freedesktop_os_release()` would be the obvious candidate.
CI: redirect stderr→stdout on Windows during build
In CI, the Windows environments run ci/build_windows.py to orchestrate
compilation. This is run under PowerShell, which has the surprising behavior of
(1) hiding stderr and (2) considering any output to stderr a signal to abort the
running program. The combined effect of this is that benign CMake logging
statements like:
message(WARNING "hello world")
abruptly terminate compilation with the baffling output:
This behavior appears to be configurable, but it seems simpler to work around
this by avoiding any stderr output. The exit status of any build commands is
sufficient to signal failure.
fix 'dot' test helper failing to encode string input
When asking the `dot` helper function to process a graph from inline input to a
binary output format, the `universal_newlines=True` parameter would not be
passed to the underlying `subprocess.check_output` call, resulting in failure to
encode the input. That is, something like the following:
dot("png:gd", source="digraph { a -> b; }")
would result in:
self = <subprocess.Popen object at 0x7fbb862ae390>
def _communicate(self, input, endtime, orig_timeout):
…
> input_view = memoryview(self._input)
E TypeError: memoryview: a bytes-like object is required, not 'str'
/usr/lib64/python3.6/subprocess.py:1519: TypeError
Note that this problem was latent, as no usage fitting the above scenario
currently exists. Something like this will be introduced in a future commit.
Commit c334e4e81aad15d3092d7c25038a4d2cf1cbff05 altered this step to only
install RPMs necessary for the test suite at the time. However, an upcoming
commit that enables `dot_builtins` causes graphviz-nox-* to depend on
libgvplugin_webp.so.6 that was not being installed. For simplicity, the present
commit reverts c334e4e81aad15d3092d7c25038a4d2cf1cbff05.
Note that this more closely matches the only reasonable way to use the
CI-produced RPMs: install all of them.
An upcoming commit will install the Graphviz R language bindings. These depend
on the `R` package that is not a dependency of any other currently installed
package.
An upcoming commit will install the Graphviz Perl language bindings. These
depend on the `perl` package that is not a dependency of any other currently
installed package.
API BREAK: fix: typedef 'ssize_t' to 'SSIZE_T' on Windows
In several places, code was using `int` as a drop-in replacement for `ssize_t`
on Windows where it does not exist. This is incorrect on some platforms. E.g. on
x86-64 this will result in `ssize_t` being a 32-bit type instead of a 64-bit
type. This change replaces it with the correct Windows equivalent, `SSIZE_T`.¹
A simpler way of achieving the warning squashing the comment here is implying
(uninitialized struct members) is to avoid the use of a static variable
altogether. Beyond being simpler, this explains to the compiler the contents of
this variable do not need to be preserved across calls and gets this function
closer to being thread safe.
grammar.y pop: [nfc] fix incorrect pop from global stack
This function was incorrectly referencing the global stack, `S`, instead of the
stack passed in. This change is marked NFC because `pop` is only ever called
with `S` as a parameter, but it still seemed worth correcting.
CMake: add a variable substitution step for plugin configuration step
This CMake script hard codes some library paths in a way that thwarts
user/system preferences (#1973). Attempts to solve this by falling back on
standard CMake mechanisms have been unsuccessful because an install script like
this runs in an isolated environment where it (correctly) does not have access
to the configuration from the build environment. To resolve this we need a way
to pass the install script parameters/arguments from the build context.
Introducing a level of indirection here gives us such a mechanism.
This change by itself does nothing. However an upcoming change will take
advantage of the `@…@` substitution mechanism enabled by this change.
Note that the word “configure” in these files is used to refer to two distinct
mechanisms:
1. The CMake `configure_file` command does something analogous to Autotools’
variable substitution during `./configure`.
This is a dependency for building Gvedit on macOS. Note that installation is not
added to the CMake test job because Gvedit is not currently built in the CMake
build system on macOS.
This is the equivalent of aa695fabf4ff342488229aabd43c0970470d711f and friends,
but for Gvedit. It was not previously detected that this problem also affects
Gvedit because it is not currently built on macOS in CI. That will be improved
in an upcoming commit.
projects / graphviz / log