treat 'X_OK' as an alias of 'R_OK' in the Windows unistd.h shim
This is not technically correct (Windows does not have `X_OK` at all), but this
is an accurate approximation for the ways in which Graphviz uses `X_OK`. This is
another step towards replacing lib/ast/compat_unistd.h.
This will enable further migration away from lib/ast/compat_unistd.h. Note that
the `S_ISDIR` wrapper there appears incorrect, in using a platform-specific
constant for the mask. Its definition of `X_OK` also seems incorrect, as this
value has no documented meaning when calling `_access` on Windows.
(1) is more comprehensive than (2), and we would like to replace (2) entirely
with (1). However, it is not currently possible to put (1) in the compiler’s
include path during the CMake build. Because it lives in the same directory as
the config.h used in the MS Build build, putting it in the compiler’s include
path also makes this config.h eligible for inclusion. This conflicts with the
CMake build system’s own generated config.h.
Moving this unistd.h to its own directory allows us to more selectively put it
in the include path when relevant. Though surprisingly this file seems unused
right now; even the adjacent config.h does not define `HAVE_UNISTD_H`,
indicating it should not be included.
With unistd.h available natively on every supported platform except Windows,
this change should allow removing unistd.h detection in future and
unconditionally including it when desired.
lib/neatogen: replace inline stack with generic implementation
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation. This also introduces some missing allocation failure checks.
This seems to be support for some legacy platform lost to the sands of time.
Various internet code searches turn up some clues, but I cannot precisely
determine what platform or system was expected to define these. AFAIK these are
undefined on all currently supported Graphviz platforms.
With the `Agiodisc_t` output function now taking a format string, this code can
be written more readably and concisely. This also avoids the need for
intermediate buffering.
With the `Agiodisc_t` output function now taking a format string, this code can
be written more readably and concisely. This also avoids the need for
intermediate buffering.
pack: replace inline stack with generic implementation
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation.
Even when this is fixed to not crash, it should still not exit with success
because the input it is given is invalid. Unfortunately we need to also adjust
the xfail condition to be non-strict because this passes under ASan, due to
exiting with 1 when an invalid memory reference is detected.
This appended path was clearly wrong. Yet this test was running (and passing) in
CI. It seems somehow `./rtest` is already in the `$PYTHONPATH` in CI. A bit
mysterious, but this correction lets the test suite run locally correctly too.
dotgen: replace inline stack with generic implementation
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation.
This macro was implemented to optimize the case of calling `gvputs` with a
string literal. It has since proven error prone to use.¹ The sharp edge is that
it is possible to call the macro with something that is not a string literal:
This will pass through the compiler with no warnings, but on e.g. x86-64 will
result in a `gvputs` of `"hello wo"`. For safety, we remove it.
This effectively reverts commit 1764f50bcbdf944e003fe475aba2c26e2fd370ff. The
`GVPUTS` macro was originally introduced to optimize I/O resulting in a ~1%
runtime improvement on tests/regression_tests/large/long_chain. That example
should probably no longer be considered “expensive.” I/O is typically an
insignificant fraction of the computation done by currently known expensive
inputs that spend most of their time in layout or cycle resolution. If I/O _is_
a factor in an expensive graph, we could consider providing a vectorized
interface in future in the style of `writev`.
¹ E.g. https://gitlab.com/graphviz/graphviz/-/merge_requests/2472#note_861834540
David Seifert [Sun, 17 Apr 2022 10:53:37 +0000 (12:53 +0200)]
Simplify PDF generation
* Make the suffix rule visible unconditionally, make only the PDF
target (`pdf_DATA`) visible if `groff` is available and the user
hasn't explicitly disabled PDF generation.
This exit wrapper works around an issue where processes running under MinGW can
exit with unbuffered data remaining in their stdout and stderr internal buffers
without being flushed. The C stdio and C++ iostreams implementations can have
separate buffers. Thus when using this wrapper in C++ code in combination with
C++ iostreams (e.g. cmd/mingle/minglemain.cpp) we need to additionally flush the
C++ buffers as well.
gvgen: replace inline stack with generation implementation
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation. This also introduces some missing allocation failure checks.
sccmap: replace inline stack with generation implementation
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation. This also introduces some missing allocation failure checks.
Without this change, attempting to include geomproc.h in render.h
would cause the following warning:
In file included from /home/magjac/graphviz/lib/common/shapes.c:12:
/home/magjac/graphviz/lib/common/render.h:24: warning: "__USE_GNU" redefined
24 | #define __USE_GNU
|
In file included from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33,
from /usr/include/limits.h:26,
from /usr/lib/gcc/x86_64-linux-gnu/11/include/limits.h:203,
from /usr/lib/gcc/x86_64-linux-gnu/11/include/syslimits.h:7,
from /usr/lib/gcc/x86_64-linux-gnu/11/include/limits.h:34,
from /home/magjac/graphviz/lib/common/arith.h:21,
from /home/magjac/graphviz/lib/common/geom.h:16,
from /home/magjac/graphviz/lib/common/geomprocs.h:21,
from /home/magjac/graphviz/lib/common/shapes.c:11:
/usr/include/features.h:407: note: this is the location of the previous definition
407 | # define __USE_GNU 1
|
This is casued by arith.h defining _GNU_SOURCE to 1 which seems to
implicitly set __USE_GNU.
gml2gv: replace 'liststk' stack with generic implementation
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation. This also introduces some missing allocation failure checks.
graphml2gv: replace custom 'slist' string stack with generic stack
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation. Apart from reducing code duplication and complexity, this
removes an unnecessary rounding of allocations. The prior code rounded up
`slist` allocations to `sizeof(void*)`, but `malloc` effectively does this
internally anyway.
graphml2gv: replace inline stack implementation with generic API
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation. This removes the previously hard coded nested subgraph limit of
32. The number of supported subgraphs in now solely limited by available memory.
bcomps: replace inline stack implementation with generic API
Similar to previous changes to `gc` in 4e2875fd7376338259dcb3ccc8f029d58bdf22dd,
this replaces some duplicated functionality with the generic Graphviz stack
implementation.
David Seifert [Sat, 16 Apr 2022 16:00:18 +0000 (18:00 +0200)]
Define `$(pkgconfigdir)` using `PKG_INSTALLDIR` in configure.ac
* This allows overriding the default using `--with-pkgconfigdir`
passed to the configure script. FreeBSD for instance doesn't use
the standard `$libdir/pkgconfig` directory. This macro has been
present in pkg.m4 for over 9 years:
https://gitlab.freedesktop.org/pkg-config/pkg-config/-/commit/5fc77a96b7a1114e296f968037342f060d4bc34b
David Seifert [Sat, 16 Apr 2022 16:00:18 +0000 (18:00 +0200)]
`$(txtdir)` -> `$(docdir)`
* All documentation directories should be a function of `$(docdir)`, and
not `$(datadir)`, which is to be used for files that the program
actually needs at runtime.
* Also amend the debian install rules, since documentation is now
natively installed into `$(docdir)` == `usr/share/doc/graphviz`.
David Seifert [Sat, 16 Apr 2022 16:00:18 +0000 (18:00 +0200)]
Let Autoconf set `$(htmldir)`
* The previous variable would not respect `--docdir` passed to configure.
Autoconf sets `$(htmldir)` to `$(docdir)` by default and AC_SUBST()s
this value.
David Seifert [Sat, 16 Apr 2022 16:00:18 +0000 (18:00 +0200)]
Let Autoconf set `$(pdfdir)`
* The previous variable would not respect `--docdir` passed to configure.
Autoconf sets `$(pdfdir)` to `$(docdir)` by default and AC_SUBST()s
this value.
projects / graphviz / log