An upcoming commit in the series need to perform this check from
C++. Using the LAYOUT_DONE macro directly would give the warning
below. It would be possible to change the underlying C functions to
take a const char * instead, but exposing this new function seems
better than using a macro in C++ anyway.
The warning that would have been the result otherwise:
In file included from /home/magjac/graphviz/lib/gvc++/GVContext.h:5,
from /home/magjac/graphviz/lib/gvc++/GVLayout.cpp:6:
/home/magjac/graphviz/lib/gvc++/GVLayout.cpp: In constructor ‘GVC::GVLayout::GVLayout(const std::shared_ptr<GVC::GVContext>&, const std::shared_ptr<CGraph::AGraph>&, const string&)’:
/home/magjac/graphviz/lib/gvc/gvc.h:38:38: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
38 | #define LAYOUT_DONE(g) (agbindrec(g, "Agraphinfo_t", 0, TRUE) && GD_drawing(g))
| ^~~~~~~~~~~~~~
/home/magjac/graphviz/lib/gvc++/GVLayout.cpp:18:9: note: in expansion of macro ‘LAYOUT_DONE’
18 | if (LAYOUT_DONE(g->c_struct())) {}
| ^~~~~~~~~~~
add a GVLayout class with construction from AGraph and GVContext objects
The GVLayout class is an RAII-class that performs a layout using
shared pointers to AGraph and GVContext objects. It participates in
the handling of the lifetime of those objects, since it needs them to
free the layout when the GVLayout object is destroyed. It currently
supports construction with built-in plugins, move construction and
move assignment, but not copy construction or copy assignment since
the AGraph and GVContext objects do not support that.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2001.
configure the dot layout plugin for use pre-installation
When running ctest, the Graphviz shared libraries are used from the
locations where they reside directly after being created, i.e., before
they are copied to the installation directory by cpack. Since the
pre-configuring of the Graphviz plugins that cpack does is done on the
installed plugins, the pre-install plugins need to be configured
separately.
We use GVBINDIR for this. It tells Graphviz both where to find plugins
and where to read and write the plugin configuration file,
config6. Unfortunately this means that we can only use one plugin
since the others are in separate directories and Graphviz currently
supports only one path in GVBINDIR. We choose to configure the dot
layout plugin which is good for now.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2001.
archive the just-built dot program in the Ubuntu 21.04 ctest CI job
In an upcoming commit in this series, the dot program will be used by
the ctest CI jobs to configure plugins for pre-install tests without
built-in plugins. This extra archiving is needed since these tests use
the dot program from the location where it resides directly after
being created, i.e., before it is copied to the installation directory
by cpack.
Towards https://gitlab.com/graphviz/graphviz/-/issues/2001.
add a new gvc++ library with a very basic GVContext C++ class
The GVContext class is an RAII-class that handles the lifetime of the
underlying GVC_t C data structure. It currently supports construction
with or without built-in plugins, move construction and move
assignment, but not copy construction or copy assignment since the
underlying C data structure cannot be easily copied. It also supports
retrieving a non-owning pointer to the underlying GVC_t.
The new gvc++ library is optional and can be enabled with the CMake
option "with_cxx_api".
Towards https://gitlab.com/graphviz/graphviz/-/issues/2001.
add a new cgraph++ library with a very basic AGraph C++ class
The AGraph class is an RAII-class that handles the lifetime of the
underlying Agraph_t C data structure. It currently supports
construction from DOT source, move construction and move assignment,
but not copy construction or copy assignment since the underlying C
data structure cannot be easily copied. It also supports retrieving a
non-owning pointer to the underlying Agraph_t.
The new C++ API is optional and can be enabled with the CMake option
"with_cxx_api".
Towards https://gitlab.com/graphviz/graphviz/-/issues/2001.
Magnus Jacobsson [Thu, 22 Jul 2021 20:04:25 +0000 (22:04 +0200)]
run ctest before installing packages in CI
This ensures that ctest can only use libraries, headers and
executables from the locations where they are built, i.e., before they
are copied to the intallation directory by cpack. This change should
have no impact, but is made to avoid doubt of which files are used in
ctest.
Instead of constructing a string in the `tmp` buffer and then eventually
allocating vmalloc space to copy this into, we can simply compute the number of
bytes in advance, allocate vmalloc space, and then directly emit the output into
the vmalloc buffer. Related to #1873, #1998.
Instead of constructing a string in the `tmp` buffer and then eventually
allocating vmalloc space to copy this into, we can simply compute the number of
bytes in advance, allocate vmalloc space, and then directly emit the output into
the vmalloc buffer. Related to #1873, #1998.
Instead of constructing a string in the `tmp` buffer and then eventually
allocating vmalloc space to copy this into, we can simply compute the number of
bytes in advance, allocate vmalloc space, and then directly emit the output into
the vmalloc buffer. Related to #1873, #1998.
Instead of constructing a string in the `tmp` buffer and then eventually
allocating vmalloc space to copy this into, we can simply compute the number of
bytes in advance, allocate vmalloc space, and then directly emit the output into
the vmalloc buffer. Related to #1873, #1998.
Instead of constructing a string in the `tmp` buffer and then eventually
allocating vmalloc space to copy this into, we can simply compute the number of
bytes in advance, allocate vmalloc space, and then directly emit the output into
the vmalloc buffer. Related to #1873, #1998.
Instead of constructing a string in the `tmp` buffer and then eventually
allocating vmalloc space to copy this into, we can simply compute the number of
bytes in advance, allocate vmalloc space, and then directly emit the output into
the vmalloc buffer. Related to #1873, #1998.
Instead of constructing a string in the `tmp` buffer and then eventually
allocating vmalloc space to copy this into, we can simply compute the number of
bytes in advance, allocate vmalloc space, and then directly emit the output into
the vmalloc buffer. Related to #1873, #1998.
Instead of constructing a string in the `tmp` buffer and then eventually
allocating vmalloc space to copy this into, we can simply compute the number of
bytes in advance, allocate vmalloc space, and then directly emit the output into
the vmalloc buffer. Related to #1873, #1998.
This fixes the following warning with clang in mingw
warning: non-portable path to file '<gdiplus.h>'; specified path differs in case from file name on disk [-Wnonportable-include-path]
gcalloc: fix: do not abort on calloc(0, x) or calloc(x, 0) returning NULL
Commit 43a37bedd934bde50a6441766b85dfc9648abda9 added a `calloc` wrapper but
mistakenly did not account for it being valid for `calloc` to return `NULL` when
the input arguments are 0. This is unlikely to have caused a problem with Glibc
whose allocator typically returns non-null pointers even for 0 allocations.
However assuming a 0 allocation may return a null pointer is more portable.
This worked out correctly, as _WIN32 is defined to 1 on Windows and is undefined
elsewhere. But it triggered -Wundef compiler warnings on non-Windows platforms.
By the nature of how Graphviz makes use of Python, some test sources are long
files of independent functions. It does not make sense to split these up and
having long files is not an impediment to maintaining these test cases.
This avoids a latent problem wherein Python is installed to a directory
containing its version number and the follow on `Path` manipulation was hard
coded to Python 3.9. This would have broken as soon as Python 3.10 became
available through Chocolatey. Closes #2085. Note, I still do not understand why
the documented technique Chocolatey recommends of `refreshenv` does not work.
scformat: use vmalloc instead of vmresize when processing '['
Though it is hard to see, the previous code bottomed out in a call to vmresize.
After allocating, it zeroes the allocated region. So vmresize (itself calling
realloc) signals an unnecessary constraint to the allocator that previous data
in this memory must be preserved.
To simplify this, this change converts the sequence to a vmfree of the prior
memory and then a new vmalloc, more clearly divorcing the new buffer from the
old one.
Buffers of length MAXNAME are printed into, including in a case where the
printed string is "(EXTERNAL:%d)". This needs a maximum of 23 bytes, not 16
bytes as was previously used. This overflow looks impossible to actually trigger
because I believe this code path is only used in the case of a bug in the lexer
itself. Hence no changelog entry for this.
This issue was exposed when moving sfsprintf calls to snsprintf, as the compiler
understands the semantics of the latter and knows how to warn about detectable
overflows. Related to #1998.
It is not clear to me what the purpose of this variable is/was. This Makefile
was added in adf9f9ad70662c0ca291feea1eb51df113c7d281. Even in that revision,
the variable was unused and refers to the non-existent file graph.tex.
projects / graphviz / log