Re: Python2 and Python3 checks

[Matěj Týč]

On 22.3.2018 14:48, Bob Friesenhahn wrote:
> On Thu, 22 Mar 2018, Matěj Týč wrote:
>
> > On 21.3.2018 22:34, Bob Friesenhahn wrote:
> > > ...
> >
> > 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.

You are right, there will be an effort to default to Python3, but there 
will be lots of cases when some people will go for Python2 and others 
for Python3 support of a piece of software.

> > > ...
> > 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.

Yes, this is exactly what I would like to achieve. And I would like to 
stress out that it is not about the macro - although the macro is 
essential, other parts of Automake besides m4 macros have to be 
accommodated, as I have pointed out in my previous mails (tl;dr - 
compiling Python script). Main users of Python Automake support are 
developers of C/C++ libraries that provide Python bindings, typically 
using SWIG. The Nate's post exactly illustrates that.

> 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.

I may not understand what you meant correctly - I see there are 
conservative distributions, but if I want my software to work well to 
develop for them, I will want to use up-to-date automake to benefit from 
it. It will make my software package work better on those distributions, 
but I can develop it on a more bleeding-edge distro s.a. Archlinux or 
Fedora.