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