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.
A refactor in 7731b18f403b545ea6eca99f429dd9b63e0659d6 incorrectly flipped the
polarity of one of the return sites in inside_polygon. The effect of this was
confusing assertion failures. Fixes #2082.
gvmap opens a debugging file to write timing information to if verbosity is
enabled. It tried to unconditionally close this file, regardless of whether
verbosity was enabled. The result was that, without verbosity enabled, it would
call fclose(NULL). The effect of this seems to vary across operating systems but
can result in a crash. This fix only tries to close the file if it was
previously opened. Related to #1822.
Unfortunately we cannot un-xfail test_gvmap_fclose because it fails for another
reason on some platforms.
As discussed on #1822, gvmap currently crashes sometimes. It seems this is not
input dependent, but rather platform dependent. A fix will arrive in an upcoming
commit.
projects / graphviz / log