agbindrec: realign parameter names in prototype with definition
The C compiler does not care if these names mismatch, but it is less confusing
to be consistent. This change leaves the obj/arg_obj discrepancy alone under the
justification that "arg_obj" is not any more useful externally-facing and "obj"
internally would conflict with an already existing local.
add archiving of VERSION and COLLECTION to all build jobs
An upcoming commit will remove the dependency to the portable-source
job for all test jobs, so it must be possible the retrieve these files
from the corresponding build job instead. Note that this is used only
for jobs using the portable source which have these files built into
them. Other jobs generate these files as needed.
Magnus Jacobsson [Wed, 11 Aug 2021 18:21:39 +0000 (20:21 +0200)]
remove the dependency on the portable-source job for CMake test jobs
The dependency is unnecessary since both the VERSION and COLLECTION
files are now generated in the CMake test jobs. Note that there
probably is no latency benefit by removing it, since the
portable-source job normally is faster than the CMake builds jobs.
An upcoming commit will remove the dependency to the portable-source
job for all CMake test jobs, so this file instead needs to be
generated by these jobs. Note that the COLLECTION file is generated by
the CMake test jobs already before this commit.
don't read the VERSION file for CMake builds in ci/build.sh
The CMake build system generates this file itself and nothing in this
script uses it for the CMake builds.
An upcoming commit will change the CI configuration to start the CMake
builds jobs directly without waiting for the portable-source job and
since that job produces the VERSION file, it will no longer be present
when the CMake builds jobs start.
restructure "%.*s" handling to avoid sfio dynamic allocation in expr’s printf
Rather than using the temporary sfio buffer in this code, fmt->tmp, we can just
use the original string as-is as it does not need to be modified. Apart from
slightly accelerating this code, this makes yet more progress towards removing
fmt->tmp and sfio. Related to #1998.
remove fallback "%?%K" strftime format in expr’s printf
lib/expr’s printf implementation supports a "%t" format code to print a time. If
no format is provided for this, it would fallback to a default of "%?%K".
While working on #1998, one of my intermediate refactorings moved this string
literal into the actual call to strftime. At this point the compiler politely
interjected that neither "%?" nor "%K" are format strings understood by
strftime. So it seems this results in an invalid call to strftime.
To deal with this, we now throw an error when this function is called with no
format string instead of making an invalid strftime call.
The caching done by this function is no longer necessary. All usages of it have
been refactored to use standard library functionality which does caching at the
operating system level.
pathpath: replace PATH_REGULAR pathexists call with a stat.
This effectively inlines and simplifies the call to pathexists that previously
existed. The caching pathexists does is no longer relevant. An improved version
of this is provided by a modern operating system’s buffer cache.
pathpath: replace PATH_EXECUTE pathexists call with X_OK access call
This is equivalent and relies solely on standard library functionality. This
effectively inlines and simplifies the call to pathexists that previously
existed. The caching pathexists does is no longer relevant. An improved version
of this is provided by a modern operating system’s buffer cache.
This function is only ever called with a=="". There is probably more
simplification possible within pathpath, but the logic is convoluted. Better to
unwind this mess in a separate commit.
The first layout of a graph must be destroyed before a second layout
is created.
This failure went undetected in CI since no test programs ran, which
in turn was caused by not archiving the test programs or the
CTestTestfile.cmake files in the preceding build job.
The error message was:
-------------------------------------------------------------------------------
Multiple layouts of the same graph can use different contexts passed as rvalue
refs
-------------------------------------------------------------------------------
../tests/test_GVLayout_construction.cpp:139
...............................................................................
../tests/test_GVLayout_construction.cpp:139: FAILED:
due to unexpected exception with message:
Previous layout not yet destroyed
No CTestTestfile.cmake files were archived in the build job that
created them, which had the effect that the suceeding test job
silently did not find any ctest tests.
pathgetlink: use a ssize_t locally, squashing -Wsign-conversion warnings
The type of the local used now matches the return type of readlink. This avoids
several compiler warnings. pathgetlink.c now builds warning-free on Linux.
pathcanon: avoid reusing `dots` variable for unrelated values
This branch reuses the `dots` variable, previously used for counting the number
of periods in the path, for storing the result of symlink resolution. This is
unnecessary (`dots` is immediately overwritten with the value 4 after this), and
is getting in the way of cleaning up some compiler warnings in this area.
destroy first layout before creating second in multiple layouts test
An upcoming commit in this series will change the implementation to
throw an exception if the previous layout has not been destroyed when
a second layout is created.
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.
projects / graphviz / log