Nothing in the build systems defines this. In a modern build environment, a
caller can achieve the effect this code path was providing by using the
compiler’s link-time optimization options.
The 6.0.0 release was bungled, resulting in multiple commits¹ that claimed to be
Graphviz 6.0.0. ddd69c589483b31f589834e49ae902142cd4df38 of the website
repository² deleted the 6.0.0 download links and we have deleted the 6.0.0 tag
in this repository.
This commit updates the changelog to indicate there was no 6.0.0 release and the
next release will be 6.0.1. Hopefully things will go smoother this time around.
Unfortunately the situation with 6.0.0 was predictable. Discussion on #2202
covered a hole in the release procedure, which turned out to be the exact
problem that occurred.
On GTK 2, the only valid scroll values are left, right, up, and down. GTK 3 adds
a fifth, smooth, capture scrolling in a combined x/y direction (diagonal). In
all cases except up and down, it seems clear this code intends to ignore the
action.
As of this commit, the GTK plugin builds warning-free on Linux.
GTK plugin: squash -Wsign-compare, -Wsign-conversion warnings for width/height
Graphviz deals with these values as unsigned, but the GTK APIs deal with them as
signed. Nevertheless we expect both sides to only ever deal in non-negative
values.
This squashes a -Wsign-conversion warning. We need to cast back to `int` for
calling `gvpr`, but this is acceptable as the number of arguments cannot
practically exceed `INT_MAX`.
These constants were added in 1b847b5abf50d2ab0701523b90a20306d0ee5528 and it is
unclear why, given they are unused. They shadow a different constant in
general.h, causing compiler warnings.
This reverts commit 2d7852a049b729fb0db71c5a8ef2366215ae2035. This commit
introduced a bug where the string buffer was assumed to be uninitialized when
beginning parsing a string, but it may not be if a previously unterminated
string was processed.
Github: fixes #2272 Reported-by: Rob Hart <robhart@google.com>
Magnus Jacobsson [Wed, 24 Aug 2022 07:37:07 +0000 (09:37 +0200)]
tests: add new test_edge_node_overlap_simple test
Upcoming commit series will add additional such tests so most of the
code is in a separate utilities file and is somewhat more generalized
than what is strictly necessary for this first simple test.
label doxlabel: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
label xlhdxload: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
GD plugin vrml_begin_job: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
core plugin write_edges: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
Magnus Jacobsson [Sat, 20 Aug 2022 16:12:54 +0000 (18:12 +0200)]
tests: SVGAnalyzer: add 're_create_and_verify_svg' method and use in test_svg_analyzer
Upcoming commits will extend the SVG analyzer's ability to handle new
SVG attributes and add new test cases verifying its ability to
re-create correct SVG containing those attributes. This change will
facilitate the creation of those tests and keep the code DRY.
Magnus Jacobsson [Sat, 20 Aug 2022 16:12:54 +0000 (18:12 +0200)]
tests: SVGAnalyzer: extend 'make_from_dot' method and use in test_svg_analyzer
This change adds support to the SVGAnalyzer for saving a
copy of the Graphviz version and build ID which are needed to exactly
re-create the SVG document.
Upcoming commits will extend the SVG analyzer's ability to handle new
SVG attributes and add new test cases verifying its ability to
re-create correct SVG containing those attributes. This change will
facilitate the creation of those tests and keep the code DRY.
tests: SVGAnalyzer: save a copy of the original SVG and give access to it
This is needed to be able to verify the SVG re-creating capablility of
the SVGAnalyzer.
Upcoming commits will extend the SVG analyzer's ability to handle new
SVG attributes and add new test cases verifying its ability to
re-create correct SVG containing those attributes. This change will
facilitate the creation of those tests and keep the code DRY.
The copying is necessary since the original SVG is modified by the XML
parser in destructive mode. See
http://rapidxml.sourceforge.net/manual.html#namespacerapidxml_1destructive_non_destructive
and we don't want to use the non-destructive mode since no entity
reference translation is done then and we want to avoid having to do
that ourselves.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho mkMazeGraph: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho partition: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho monotonate_trapezoids: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho make_graph: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho createSGraph: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho initSEdges: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho construct_trapezoids: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho orthoEdges: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho attachOrthoEdges: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho extractVChans: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho extractHChans: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
ortho convertSPtoRoute: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
projects / graphviz / log