The third-party library Svgpp calls Boost in a way that is deprecated, resulting
in compiler warnings during the CMake build. This change teaches CMake that none
of this is our code and we do not want to be warned about it.
Given the prior commit rewrote every byte in this file, we may as well also fix
the odd white space decisions here while we are at it. Though it is unclear who
if anyone uses this tool any more.
Of all the source files in the Graphviz tree, this file alone was encoded in
UTF-16 with a BOM.¹ BOMs have mostly fallen out of favor these days, with people
preferring to let the host operating system or locale determine encoding. Git
will happily translate text files to your local encoding on checkout. With that
in mind, we can convert this file to UTF-8 and stop forcing developers on other
operating systems to pay the price for Windows’ poor past decisions.
xlib plugin handle_file_events: more tightly scope a long-lived dynamic buffer
This buffer was being retained in a long-lived `static` pointer, increasing peak
memory usage and making it harder to use tools like Valgrind and ASan with
Graphviz. This change makes it more obvious to both users and tools what this
buffer is used for.
Note this also tweaks an error message to be more informative.
This seems to have gone unnoticed because none of the Graphviz components
currently integrated into the CMake build system rely critically on fcntl.h.
This issue was discovered when integrating the xlib plugin.
Costa Shulyupin [Sun, 27 Mar 2022 04:09:51 +0000 (07:09 +0300)]
gvpr: initialize a variable
Squash
warning: ‘alpha’ may be used uninitialized in this function
One branch of conditional statement leaves variable alpha
uninitialized. Actually uninitialized value is not used,
but compiler still complains. So just add one assignment to
assumed 0.
BTW, the code can be refactored and shortened.
But it is preferable to just minimize the changes.
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.
projects / graphviz / log