In tclpkg/gv, the gv_doc_writer.tcl is run multiple times during
the build. It is ineffective, but it shouldn't cause any troubles
with the serial build. Unfortunately, this is not the case with
the parallel builds where multiple parallel runs of the
gv_doc_writer.tcl can cause races leading to empty corresponding
ps and pdf files.
The correct solution would be to use the Rules with Grouped Targets [1],
unfortunately this GNU make feature has been introduced quite
recently which would break backward compatibility.
The proposed hack should cause the gv_doc_writer.tcl to be run
only once during the build process and it should work also with
the older 'make'. It is inspired by [2].
remove Python 2 support from shapes regression test
Python 2 was EOLed in 2020. This change removes the ability to use Python 2 when
running the shapes test.
This is somewhat moot as the Makefile.am targets for this are not really usable
right now (see the commits merged in 7d0bd41a7ccac1d0d992e8c19ce08f62b85b16ad
that improved the situation but still did not make `make check-recursive`
runnable). Nevertheless this at least removes one legacy code path that does not
need to be worked on in future.
The existing CI tasks run an uncommon work flow: building distributable packages
on each operating system. A more common work flow end users will be following
with the portable source tarball is simply building and installing it. This
change adds a job that does this, to provide a safeguard against breaking this
work flow in future.
The added job runs on Ubuntu 21.04. The intent is to bump this job to the latest
each time there is a new Ubuntu release. There is no companion test job for the
build job because we assume the existing test jobs are providing sufficient
coverage.
The rules that generated these bindings were all removed in 3caeb0ae2a38fdefb9f302f41407f5038e374010 but the clean up steps were incorrectly
not removed at the same time. Related to #1992.
remove unnecessary casts of allocation function results in grammar.y
This input is only used to generate a parser in C. In C, void pointers (as are
the results of all the allocation functions) implicitly coerce to all other
pointer types.
remove unnecessary casts of allocation results in mklang.y
This input is only used to generate a C file. In C, void pointers (as are the
results of all the allocation functions) implicitly coerce to all other pointer
types.
remove unnecessary casts of allocation results in gmlparse.y
These functions all return void pointers and this input is only used for
generating a parser in C. In C, void pointers implicitly coerce to all other
pointers.
Python 2 was EOLed in 2020. This change removes support for building Graphviz
bindings for Python 2, as well as build system detection of Python 2. The
targets for `python` as distinct from `python3` are left in place for
environments for which the former is their name for Python 3.
The Autotools build system looks for the C header Python.h to determine the
include path for the local Python installation. However, on Ubuntu 18.04 it was
not finding it. The reason is that the libpython3-dev package on Ubuntu 18.04
installs Python 3.6 under a “python3.6m” prefix that it does not add to C/C++
include paths. This seems to be a deliberate choice in the structure of this
package for Ubuntu 18.04, to avoid conflicts with default Python 2.
A reasonable question to ask is then why Python 3 detection succeeds on the CI
Ubuntu 18.04 jobs. The answer is that libpython2-dev is installed. That is, the
Python 3 detection finds the Python.h from the libpython2-dev installation and
incorrectly assumes it has found the Python 3 header. This confusion may play a
role in #227 and #1042.
This coincidental alignment of headers is exposed when libpython2-dev is removed
and Python 3 detection starts failing. This commit pre-empts this failure in
upcoming changes that remove Python 2 support by explicitly making the Python 3
Python.h findable. Related to #1992.
remove PYTHON variable in Fedora/RHEL/CentOS packaging
This is now false for all operating systems. Across all supported versions of
Fedora, RHEL, and CentOS Python 2 and Python 3 have consistent package names. So
there is no need to deal in the ambiguous Python names with no version number.
Related to #1992.
These values are now the same as the default Fedora settings preceding them, so
there is no need for RHEL-/CentOS-specific values here. Related to #1992.
set enabled Python bindings uniformly on RHEL/CentOS
0af0dc91894f2598f0e19e3cd2c1b34925c9cd61 introduced a workaround for Python
packages changing names. This was relevant in the era of CentOS 6. However, now
Graphviz no longer supports CentOS 6 and furthermore CentOS 7 has converged on
the same naming as CentOS 8. As a result, the Graphviz packaging work flow was
actually *disabling* Python 3 bindings and enabling Python 2 bindings on CentOS
7.
This change unifies which Python bindings are enabled across RHEL and CentOS
versions. Though an upcoming change will remove support for the Python 2
bindings altogether. Related to #1992.
remove useless juggling of CPPFLAGS in Python 2 detection
This was copied from the unified Python support in 32466ecc452102a1fc84f4331c0ed099da4e7edc without noticing Python 2 needs no
tweaking of the CPPFLAGS. Related to #1992.
Python 3’s major version is, by definition, 3. These tests were copied from
the unified Python support in 32466ecc452102a1fc84f4331c0ed099da4e7edc with
seemingly not much consideration of what their intent was. Related to #1992.
Python 2’s major version is, by definition, 2. These tests were copied from
the unified Python support in 32466ecc452102a1fc84f4331c0ed099da4e7edc with
seemingly not much consideration of what their intent was. Related to #1992.
fix typo in error message when failing to find Python 2 install dir
32466ecc452102a1fc84f4331c0ed099da4e7edc replicated the unified Python bindings
support into Python 2 and Python 3 cases. However, it incorrectly used the
Python 3 variable in this error message instead of the Python 2 variable.
Related to #1992.
These were copy-pasted from the generic Python support in 32466ecc452102a1fc84f4331c0ed099da4e7edc without noticing that they are unused
in the way Python 2 and 3 detection is written. Related to #1992.
The test suite does not currently rely on the installed Graphviz Python bindings
being findable and usable. However in future test cases may be introduced that
do. This change future proofs the instructions against an update like this.
Related to #1992.
projects / graphviz / log