use suffixed literals instead of casts to construct 'GLfloat' values
The `GLfloat` type is 32-bit IEEE-754 floating-point.¹ As of C99, the `float`
type is also 32-bit IEEE-754 floating-point on all platforms with support.² In
contemporary usage, this is effectively all C99 platforms that support
floating-point arithmetic. Graphviz has been compiled in C99 mode since commit fe3f9411d2c59b463ab1b64eecfd19f2db55d2fc. Putting those things together, we can
abbreviate the way we write `GLfloat` literals, leading to more readable code.
This parametrized test was checking the validity of checked in Graphviz HTML
sources. There is no need to run this identical check in every single CI test
job nor on end users machines where they may have differing versions of
`xmllint` installed.
OpenGL has an unorthodox API wherein the `gluTessCallback` function’s prototype
indicates it takes a `void(*)(void)`, but its docs¹ explain that the type
actually varies depending on the second argument. As a result, the compiler
(correctly) warns that some of these `gluTessCallback` calls are passing
function pointers that do not have the same ABI. Presumably this works out
because at the end of the day a function pointer is just some bits in C and the
OpenGL implementation branches on the `which` argument and invokes the pointer
correctly. But if OpenGL really wanted to discard type safety this way, it is
not clear to me why they did not make the function pointer argument a `void*`.
Anyway, this commit squashes the compiler warnings which emerge when enabling
this in the CMake build system, failing the build.
Gitlab: related to #1836
¹ This is not the authoritative source, but Microsoft’s docs for their
implementation provide a good explanation.
https://docs.microsoft.com/en-us/windows/win32/opengl/glutess
The last use of this was removed in 7e1f01ad52915498a252dd213f85daf5a058aa5d.
This causes compiler warnings resulting in build failure when enabling this in
the CMake build system.
This seems to have been broken since CMake support for lib/topfish was
introduced in 45893ca105777e1c5b97788cd169e400250ffa1f. But it was never noticed
because there is no executable in the CMake build system that links against
topfish yet.
Note that the target here is named “edgepaintib” in anticipation of future
enabling of cmd/edgepaint claiming the name “edgepaint”. This also does not
define a separate liblab_gamut, as the Autotools build does. This separate
library seems only useful for cmd/edgepaint, so it does not seem worth splitting
it out as a separate library.
This seems to have been a mistake in aadee957012e676c9aaf36ec40cb2860c178e269.
lib/edgepaint does not depend on libANN, so it does not seem correct to apply
ANN’s CFLAGS when compiling it.
CI: move macOS dependency installation out of line
Makes these a little easier to manage. Note that this also unifies the runtime
dependencies installed in Autotools and CMake jobs which simplifies ongoing
maintenance.
This is the equivalent of b4925c87f1e28a1bc66d111ef046e4e083db8c5b and friends,
but for mingle. It was not previously detected that this problem also affects
mingle because it is not currently built on macOS or Windows in CI. This will be
improved in future.
htmlparse.y: consistently treat 'kind' as a 'char'
The `kind` field in `htmllabel_t` is a `char`, so this code was causing
conversion compiler warnings when trying to assign an `int` to it. We can avoid
this ambiguity by consistently using the same type everywhere.
Nothing in the build systems defines this macro. It is also unclear how this
code could be used given it calls `pathnext`, a function that has never been
committted to the Graphviz repository.
This function was only ever called with `0` as `flags`, which disables a lot of
its logic. We can reduce the amount of ongoing code to maintain by paring this
back to just the core in use.
This change replicates and extends the exit-on-failure allocation wrappers from
lib/common/memory.c into a header-only implementation in cgraph. The existing
common wrappers worked but there were two limitations preventing their wider
use:
1. lib/common is not the base of the Graphviz dependency graph. E.g.
lib/cgraph does not depend on lib/common, preventing calling
lib/common/memory.h functions from cgraph code. lib/cgraph is not the base
of the dependency graph either (it depends on lib/cdt), but it has become a
de facto home for header-only implementations of general utility functions
called throughout the rest of the Graphviz code base.
2. lib/common is not linked against by every Graphviz component. This meant
other code could attempt to call functions in lib/common/memory.h but would
fail to link because it was not pulling in lib/common/memory.c.
Relocating these functions neatly solves both the above two. It also has the
side effect of allowing compilers to inline these short wrappers. This could
(and would) previously be achieved with Link-Time Optimization, but now a
regular optimizing compilation can also achieve this.
Future changes will remove the lib/common/memory.c wrappers in favor of these.
Stephen C North [Mon, 7 Mar 2022 23:39:41 +0000 (18:39 -0500)]
Attempt to fix initialization of subgraph attributes on existing subgraphs…
Attempt to fix initialization of subgraph attributes on existing subgraphs when
a new root graph attribute is created.
Fix issue 2184, initialization of existing subgraph attributes when a new top
level graph attribute is created. Looks ok, but new code unviewsubgraphsattr is
executed on many of the test graphs, so this should be tested carefully.
projects / graphviz / log