04a78cc9ae01b2a7e5d5435146cd503c45af90b9 disabled Lefty in the Autotools build
system. The only fall out from this seems to have been Gentoo discovering
mistakes in the Graphviz Autotools files.¹ With mild evidence that there is no
one downstream relying on Lefty, we take the next step in its removal. If
another three months pass with no issues, we can remove Lefty from the Graphviz
tree altogether.
CC: David Seifert <soap@gentoo.org>
Gitlab: related to #1836, #1854
This macro is a legacy toggle to suppress parts of the Windows API surface in
order to accelerate compilation. In a parallel compilation of a code base the
size of Graphviz, it has a negligible effect. As always, Raymond Chen gives the
back story.¹ This commit removes these tricks to ease future maintenance.
tests: when squashing macOS 'XType' warnings, also swallow trailing '\n'
Enabling Smyrna on macOS fails the test `test_tools` because running `smyrna -?`
outputs some XType warnings prior to the usage text. Suppressing these with
`remove_xtype_warnings` still does not fix the issue because the seen text now
begins “\n\nusage:…”. This change makes `remove_xtype_warnings` act more
precisely and strip the end of line character that is part of the warning as
well.
On macOS, the OpenGL implementation is provided by the XCode SDK under the
“OpenGL/” prefix instead of “GL/” as on other operating systems. Note that
glut.h is still provided by the Freeglut package under “GL/”.
CMake: make all glcomp checks required if 'with_smyrna=ON'
Given there is a build system flag `with_smyrna` that defaults to `OFF`, it
seems to make more sense to unconditionally attempt to build glcomp when this
flag is on. The current silent disabling behavior when dependencies are missing
results in a confusing link failure when glcomp cannot be found. Following this
change, this is instead a configuration failure pointing to the missing
dependency(ies).
This test was introduced in !1347¹ in response to some version confusion due to
the Graphviz version being generated in several different places. Locally, this
test could fail misleadingly if the developer had new commits in their Graphviz
checkout and had not recompiled. But these failures are not relevant; running
the test suite against a slightly different version of Graphviz should not
unconditionally fail one of the tests. Moreover a developer working locally is
generally only running a single work flow, so their local Graphviz version is
generated in a single place.
The place where we do worry about version divergence is in CI, where the steps
for generating the Graphviz version for different platforms are in different
places and can accidentally skew. So this change makes the test only run in CI,
not locally.
Note that we can also drop the conditional logic to recover the version from the
GRAPHVIZ_VERSION file because the `$GV_VERSION` environment variable is defined
in all the CI testing jobs.
Generator expressions¹ within strings are not expanded. So these lines were
leading to confusing build output indicating the literal text of the generator
expression was being symlinked:
[ 79%] Linking C executable dot
Linking $<TARGET_FILE_NAME:dot> as circo
Linking $<TARGET_FILE_NAME:dot> as fdp
Linking $<TARGET_FILE_NAME:dot> as neato
Linking $<TARGET_FILE_NAME:dot> as osage
Linking $<TARGET_FILE_NAME:dot> as patchwork
Linking $<TARGET_FILE_NAME:dot> as sfdp
Linking $<TARGET_FILE_NAME:dot> as twopi
[ 79%] Built target dot
These patches appear to have been working around some non-portable code in the
headers shipped with Microsoft Visual Studio 8 (a.k.a. Microsoft Visual Studio
2005). This version of Visual Studio was EOLed on 2016-04-12. Neither the CMake
nor MS Build build systems (the only CI environments for which compilation of
this plugin is enabled) were using these patches. So apparently they have not
been useful for a long time.
When enabling Smyrna in the CMake build system, compilation fails with a
-Wempty-body warning about this line. I am guessing that it was intended to not
be a conditional here.
This is the equivalent of cd80b6262c7e1b95307756f13c89a9f6b2900520 and friends
but for Smyrna. It was not previously detected that this problem also affects
Smyrna because it is not currently built on macOS or Windows in CI. This will be
improved in future.
With Clang on macOS, this causes compiler warnings due to initializing a pointer
with `'\0'`. This fails the CMake build which will be enabled in a future
commit. We could rephrase this, but it is simpler to just remove this unused
member.
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.
projects / graphviz / log