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.
Again, the problem is not witch choosing the correct version of Python,
but supporting Python2 and Python3 in one project at the same time. The
Python selection can be accomplished by a m4 Autoconf macro, but the
rest has to be addressed by Automake.
Autotools is in it for the long haul since parts of it have been in
use since 1994. The issue of Python 2 vs Python 3 will eventually be
resolved and forgotten. Anything added today to solve what should be
a short term problem will be an encumberance or problem in the future.
This is just adding one level of abstraction. If designed correctly, it
could actually benefit the current code. Moreover, there won't be only
Python3 forever. The need for libraries to have bindings for multiple
Python versions will reappear again.
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.
