OCaml bindings: fix: only pass -fpermissive when compiling C++
The `-fpermissive` flag is only valid for Objective-C and C++, but was being set
for C and C++. When compiling the C part of these bindings, this was generating
the warning:
cc1: warning: command line option ‘-fpermissive’ is valid for C++/ObjC++ but
not for C
This flag was introduced in 8f4667edb410a6d11b53746849304fb953b5c6ae to work
around non-conformant code generation by SWIG. In future, it might be worth
investigating whether the underlying issue has been fixed in SWIG and this work
around can be removed.
gvpack_static: force the C++ compiler to be used also for static linking
The trick to force the C++ compiler to be used for linking was applied
only for gvpack, not for gvpack_static.
Fixes many errors like this:
/usr/bin/ld: ../../lib/vpsc/.libs/libvpsc_C.a(csolve_VPSC.o): in function `newVariable':
csolve_VPSC.cpp:(.text+0x20): undefined reference to `operator new(unsigned long)'
tools: add workaround for cpack problem with Cygwin
Copy the gml2gv executable to to the gv2gml alias instead of
symlinking it. Creating a symlink to gml2gv works fine in itself, but
results in an error like this when running cpack:
CPack Error: Problem while adding file </home/magja/graphviz/build/_CPack_Packages/CYGWIN/ZIP/Graphviz-2.49.1~dev.20210902.2049-CYGWIN/bin/gv2gml> to archive </home/magja/graphviz/build/_CPack_Packages/CYGWIN/ZIP/Graphviz-2.49.1~dev.20210902.2049-CYGWIN.zip>, ERROR = Unable to read from file 'Graphviz-2.49.1~dev.20210902.2049-CYGWIN/bin/gv2gml': Couldn't list extended attributes
gv2gml is a symlink. Trying to read the extended attributes manually gives:
attr -l /cygdrive/c/Users/magja/graphviz/build/_CPack_Packages/CYGWIN/ZIP/Graphviz-2.49.1~dev.20210902.2049-CYGWIN/bin/gv2gml
attr_list: Permission denied
Could not list /cygdrive/c/Users/magja/graphviz/build/_CPack_Packages/CYGWIN/ZIP/Graphviz-2.49.1~dev.20210902.2049-CYGWIN/bin/gv2gml
Copy the dot executable to its alias commands instead of symlinking
it. Creating symlinks to dot works fine in itself, but results in an
error like this when running cpack:
CPack Error: Problem while adding file </cygdrive/c/Users/magja/graphviz/build/_CPack_Packages/CYGWIN/ZIP/Graphviz-2.49.0~dev.20210812.2025-CYGWIN/bin/circo> to archive </cygdrive/c/Users/magja/graphviz/build/_CPack_Packages/CYGWIN/ZIP/Graphviz-2.49.0~dev.20210812.2025-CYGWIN.zip>, ERROR = Unable to read from file 'Graphviz-2.49.0~dev.20210812.2025-CYGWIN/bin/circo': Couldn't list extended attributes
circo is a symlink. Trying to read the extended attributes manually gives:
attr -l /cygdrive/c/Users/magja/graphviz/build/_CPack_Packages/CYGWIN/ZIP/Graphviz-2.49.0~dev.20210812.2025-CYGWIN/bin/circo
attr_list: Permission denied
Could not list /cygdrive/c/Users/magja/graphviz/build/_CPack_Packages/CYGWIN/ZIP/Graphviz-2.49.0~dev.20210812.2025-CYGWIN/bin/circo
ci/build.sh: remove trailing text after actual version ID
Fixes a problem on Cygwin where 'uname -r' gives:
3.2.0(0.340/5/3)
which, when used as the name of a directory, actually represents a
directory named '3.2.0(0.340', containing a subdirectory named '5'
containing a subdirectory named '3)'.
fix: write Graphviz build version to GRAPHVIZ_VERSION file instead of VERSION
C++20 standardizes a new `version` header.¹ A side effect of this is that
Autotools-driven Graphviz compilation fails when using both (1) a C++20-capable
compiler and (2) a case-insensitive file system:
Making all in vpsc
CXX block.lo
In file included from block.cpp:20:
In file included from …/include/c++/v1/memory:667:
In file included from …/include/c++/v1/type_traits:417:
In file included from …/include/c++/v1/cstddef:37:
../../version:1:1: error: expected unqualified-id
2.49.1~dev.20210907.1517
^
The core problem is that the root of the repository checkout (or unpacked
tarball) is in the compiler’s include path in order to allow including
`config.h`. But the generated `VERSION` file is also in this same directory.
Nothing in Graphviz attempts to include the C++20 `version` header, but some of
the other stdlib headers transitively include `version`.
To avoid this confusion, we rename Graphviz’ generated file.
This is attempting to shrink a buffer that was allocated by gvRenderData to its
tight bounds. This kind of thing is no longer a necessary optimization and, in
some cases, can be a de-optimization.
ci/build.sh: fix missing VERSION_ID on MSYS2/MinGW
This change will allow treating unset variables as errors in an
upcoming commit.
This problem also caused the build artifacts to be moved to the wrong
directory, but that did not have any consequences since the build
artifacts are currently not archived in the CI jobs. An upcoming
commit in this series will however change that.
Ensure correct file-level dependency for generated file in cmake generated projects
When using ninja parallel compilation, it is possible that the generated ninja
file might not create the necessary files, color_lib and svgcolor_lib, before
they are needed and this results in a failed build. Providing an absolute path
to depend on in the add_custom_command rectifies the situation.
The current Graphviz test suite is orchestrated via Pytest and assumes it is
dealing with an installed Graphviz (e.g. headers and libraries available in
expected locations). The legacy Autotools check targets gave the incorrect
impression that this was the current test suite and it was expected to pass. It
has not been possible to run these legacy test scripts for a long time.
This commit removes the legacy testing pieces to avoid future confusion. In
future it may be useful to plumb the current Pytest test suite to the Autotools
post-install test targets (`make installcheck`).
The macro defined on macOS is `__APPLE__`, not `DARWIN`. The build system
conditionally defines `DARWIN`, but config.h is not included in this file so
that has no effect. The else case of this logic is the same as the `DARWIN` case
so removing this has no effect.
SWIG is capable of targeting three Javascript runtimes when generating code:
JSC, V8, and NodeJS. One of these needs to be selected at generation time; there
is no default. In future it may be desirable to target the more popular of
these, NodeJS, but for now we leave it with the traditional JSC.
There are still multiple blockers to enabling this fully in the build system:
1. The configuration setup checks for a `js` binary. I do not know what this
is. Maybe it is intending to check for `jsc`, the JSC compiler?
2. Even if that were true, this is the wrong thing to check for. Generation of
bindings and their compilation requires not a Javascript compiler but the
runtime’s C/C++ headers. For JSC, JavaScriptCore/JavaScript.h.
projects / graphviz / log