[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Python2 and Python3 checks
From: |
Bob Friesenhahn |
Subject: |
Re: Python2 and Python3 checks |
Date: |
Thu, 22 Mar 2018 08:48:56 -0500 (CDT) |
User-agent: |
Alpine 2.20 (GSO 67 2015-01-07) |
On Thu, 22 Mar 2018, Matěj Týč wrote:
On 21.3.2018 22:34, Bob Friesenhahn wrote:
On Wed, 21 Mar 2018, Matěj Týč wrote:
The question stands like this: Is there a demand on automake side to fix
this issue - to allow developers addressing multiple Python interpreters
of different major versions? If so, I think that I can come up with some
patches to get this working.
Is there a purpose to this macro from an Automake (creating Makefiles)
standpoint? Does Automake offer special Python module building support
which depends on the Python version?
Majority of packages that use Autotools are C/C++ libraries, and they may
want to build bindings for Python. As Python2 is the only supported Python
e.g. in RHEL7, but it is also possible to obtain Python3, there will be
demand for this for years and years to come as for the developer, supporting
bindings for multiple Python major versions is a relatively cheap task.
RHEL7 is very conservative. I have heard that some major
distributions are now standardizing/defaulting to Python3, although
they allow installing Python2.
The ability to specify a maximum version sounds useful but it is difficult
to foretell the future and a package using the feature might be adding an
artificial limitation which eventually leads to failures because the
requested version range is no longer in use.
Again, the main target group is library developers providing bindings.
Projects with lots of Python code will not use Autotools at all. Therefore,
it is not so much about capping the version, but it is about distinguishing
that there may be more than one major Python version that needs to be dealt
with in the build and install process.
You make a good point that it is possible that a package will want to
discover multiple Python versions and build extensions for each
version found. Is this something you would like to support?
The question to be answered is if updating Automake's macro is the
best course (requiring updating Automake to the version providing the
macro in order to use it) or if a macro in something like the Autoconf
macro archive is the safer approach.
A stable distribution may not want to update the Automake version for
a few years but they might also want to re-autotool packages while
building them. In this case, a cached .m4 file with the macro will
still work while depending on a macro from a latest Automake won't
work because the distribution has chosen not to be up to date.
Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/