GNU logs - #13170, boring messages

Message sent to bug-automake@HIDDEN:

Subject: bug#13170: automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)
Resent-From: Stefano Lattarini <stefano.lattarini@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Thu, 13 Dec 2012 12:56:01 +0000
Resent-Message-ID: <handler.13170.B.135540336023175 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Jack Kelly <jack@HIDDEN>
Cc: brandon@HIDDEN, 13170 <at> debbugs.gnu.org, mail@HIDDEN, automake-patches@HIDDEN, bug-pyconfigure@HIDDEN
Message-ID: <50C9D003.4050702@HIDDEN>
Date: Thu, 13 Dec 2012 13:54:27 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN>
In-Reply-To: <87vcc6s1f6.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

Severity: wishlist

[+cc bug-automake, +cc bug-pyconfigure]

Reference:
<http://lists.gnu.org/archive/html/automake-patches/2012-12/msg00010.html>

On 12/13/2012 11:15 AM, Jack Kelly wrote:
> Kerrick Staley <mail@HIDDEN> writes:
>> Usually, when AM_PATH_PYTHON is invoked with an argument of the form
>> 2.X, it means that only a Python 2 interpreter should be used, and not
>> a Python 3 interpreter. However, the "python" command invokes a Python
>> 3 interpreter on some systems (see [1]), so if we try "python" first,
>> we may get a Python 3 interpreter when really a Python 2 interpreter is
>> needed. By changing the precedence so that the "python2(.X)" commands
>> are tried first, a Python 2 interpreter will always be used if one is
>> available (and of sufficiently high version).
>>
>> [1] http://www.python.org/dev/peps/pep-0394/
> 
> I disagree with this patch.
>
Me too, mostly.  But I agree that there is an underlying issue (albeit
not major).

> The "Future Changes to this Recommendation"
> section of PEP 394 anticipates changing the `python' symlink to
> `python3' at some point in the future.
>
> I think a better patch would change the search list based on the major
> version passed as the first argument to AM_PATH_PYTHON:
> a) If it's 2.x, search `python2 python2.7 python2.6 ... python'.
> b) If it's 3.x, search `python3 python3.3 python3.2 python3.1 ... python'.
> c) If nothing's given, search `python python2 python2.7 ... python2.0
>    python3 python3.2 ... python3.0.'
> 
> In case (c), swap the search order to search python3 interpreters first
> once PEP 394 updates its recommendation to make python symlink to a
> python 3 interpreter.
>
This sounds quite complex; too much, honestly.

What is more important, I don't think we should work on, tweak, nor
improve AM_PATH_PYTHON anymore.  In fact, there is a new GNU project
that aims at providing better autoconfigry integration for python:

    <https://www.gnu.org/software/pyconfigure/>

So I think that, instead of adding new code and semantics to automake,
we should work toward improving that package, and integrate with it
once it's mature enough (then we could deprecate, and some time in
the future remove, the AM_PATH_PYTHON macro from automake).

I've added the bug-pyconfigure in CC: to contact the author of that
package, and hear his opinion on the matter.  Maybe we can start
sketching out a roadmap and a TODO list ...

> Question: should this dispatch be done at `autoconf' time (via m4) or at
> `./configure' time (via sh)? If a package wants to support python 2 and
> 3, I think they should inspect $PYTHON after a call to AM_PATH_PYTHON,
> and not pass a shell variable as the first argument. Is there an
> automake convention about which arguments can safely hold shell
> variables?
> 
> -- Jack
> 

Thanks,
  Stefano

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: bug#13170: Acknowledgement (automake and pyconfigure: a future
 integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al.
 first))
Message-ID: <handler.13170.B.135540336023175.ack <at> debbugs.gnu.org>
References: <50C9D003.4050702@HIDDEN>
X-Gnu-PR-Message: ack 13170
X-Gnu-PR-Package: automake
X-Gnu-PR-Keywords: patch
Reply-To: 13170 <at> debbugs.gnu.org
Date: Thu, 13 Dec 2012 12:56:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-automake@HIDDEN

If you wish to submit further information on this problem, please
send it to 13170 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
13170: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D13170
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-automake@HIDDEN:

Subject: bug#13170: automake and pyconfigure: a future integration?
Resent-From: Stefano Lattarini <stefano.lattarini@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Thu, 13 Dec 2012 14:49:01 +0000
Resent-Message-ID: <handler.13170.B.13554100954154 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Brandon Invergo <brandon@HIDDEN>
Cc: 13170 <at> debbugs.gnu.org, bug-pyconfigure@HIDDEN, jack@HIDDEN, automake-patches@HIDDEN, mail@HIDDEN
Message-ID: <50C9DEE6.9050102@HIDDEN>
Date: Thu, 13 Dec 2012 14:57:58 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
	<87k3smt7f3.fsf@HIDDEN>
In-Reply-To: <87k3smt7f3.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

Hi Brandon.

On 12/13/2012 02:20 PM, Brandon Invergo wrote:
>>>
>> Me too, mostly.  But I agree that there is an underlying issue (albeit
>> not major).
>>
>>> The "Future Changes to this Recommendation"
>>> section of PEP 394 anticipates changing the `python' symlink to
>>> `python3' at some point in the future.
> 
> This has already happened in Parabola, Arch and other similar distros. I
> think it's best, with an eye to the future, to keep python3 at the front
> of searches.
> 
>>>
>>> I think a better patch would change the search list based on the major
>>> version passed as the first argument to AM_PATH_PYTHON:
>>> a) If it's 2.x, search `python2 python2.7 python2.6 ... python'.
>>> b) If it's 3.x, search `python3 python3.3 python3.2 python3.1 ... python'.
>>> c) If nothing's given, search `python python2 python2.7 ... python2.0
>>>    python3 python3.2 ... python3.0.'
>>>
>>> In case (c), swap the search order to search python3 interpreters first
>>> once PEP 394 updates its recommendation to make python symlink to a
>>> python 3 interpreter.
>>>
>> This sounds quite complex; too much, honestly.
> 
> What happens in pyconfigure (more on that in a moment) is that you can
> pass an argument to AC_PROG_PYTHON. So if you want to use Python 2
> specifically, you first search for it with AC_PROG_PYTHON([python2]).
> In a standard system, this should find the most recent Python 2
> interpreter.
>
Would that also find a python 2.x interpreter names simply as "python"?

> If it doesn't find anything, then do AC_PROG_PYTHON without
> an argument to search the full list. If a Python 3 interpreter is found,
> then that likely means that `python' in PATH refers to Python 3 and that
> if Python 2 *is* installed, it's installed in some weird, non-standard
> way. In that case, the user can always pass in the PYTHON env variable
> as an argument to configure.
> 
> Here's an example configure.ac chunk to do that using Pyconfigure's
> macros: 
> 
>     m4_define(python_min_ver, 2.5)
>
(Nit: missing quotes; should be "m4_define([python_min_ver], [2.5])")
More important, you define this as a m4 macro ...

>     AC_PROG_PYTHON([python2])
>     if [[ "x$PYTHON" == "x" ]]; then
>        AC_PROG_PYTHON
>        PC_PYTHON_VERIFY_VERSION(3.0, ,
>            AC_MSG_ERROR(Python 2 ($python_min_ver+) is required))
>
... but later use it a shell variable.  What am I missing?

>     fi
> 
>>
>> What is more important, I don't think we should work on, tweak, nor
>> improve AM_PATH_PYTHON anymore.  In fact, there is a new GNU project
>> that aims at providing better autoconfigry integration for python:
>>
>>     <https://www.gnu.org/software/pyconfigure/>
>>
>> So I think that, instead of adding new code and semantics to automake,
>> we should work toward improving that package, and integrate with it
>> once it's mature enough (then we could deprecate, and some time in
>> the future remove, the AM_PATH_PYTHON macro from automake).
>>
>> I've added the bug-pyconfigure in CC: to contact the author of that
>> package, and hear his opinion on the matter.  Maybe we can start
>> sketching out a roadmap and a TODO list ...
> 
> I know that I have not yet communicated with the Auto{make,conf} devs
> enough about integrating the pyconfigure files upstream. Needless to
> say, it's easiest for me to work on them and tweak them from the comfort
> of a project that I maintain.
>
Note that for "integration" I didn't mean merging your project into
Automake, but rather, having Automake leveraging on the m4 macros
provided by it; as we do with, say, the 'LT_INIT' libtool-provided
macro, without needing nor wanting it to be part of the Automake
core.

> So, I'm waiting until I get all the bugs and kinks (like
> version checking) worked out so that they require as
> little further work as possible upstream. 
>
I think that would go more smoothly collaborating with the upstreams
from the beginning; for example, we had some tweaks and bug-fixes
related to python support in Automake (see in particular the commits
v1.12.4-43-ge0e99ed and v1.12.5-14-g1f113f6 in the Automake's git
repository), and you might want to backport some of them into
pyconfigure as well.

> Currently there is Python stuff spread out between Autoconf-archive,
> Automake, and now Pyconfigure. I'm hoping to integrate the core of that
> functionality into a robust set of macros in Pyconfigure
>
+1 from me!

> (obviously some
> specialized things can/should stay in autoconf-archive). I think these
> core macros will be most appropriately integrated into Autoconf, since I
> have implemented Python as an AC_LANG.
>
Makes sense.

> Future integration with Automake will be necessary. This is a bit of a
> hand-wavy explanation but here it goes: currently Pyconfigure provides a
> standard-GNU-style wrapper around Python's distutils setup.py; the next
> step is to also offer the reverse, meaning a setup.py that essentially
> calls the standard GNU stuff. Since Pyconfigure is all about making
> things as easy as possible for maintaining these different build
> procedures, very way that I think about it, I realize
> that I would be largely rewriting Automake.
>
Well, at least those parts of Automake deals with python ;-)

And I'm open to such a rewrite, it it will brings clear advantages;
e.g., better integration/compatibility with distutils, setuptools
and/or distribute (or what the python distribution subsystem du-jour
is, sigh), clearer semantics, etc.

> What I will do is start to
> implement it very manually in the Makefile.in and once I have a clear
> idea of my needs, I'll bring it to you guys to see how we can implement
> it (sadly, I don't know the inner workings of Automake).
>
No worry, once you have working rules, integrating them shouldn't
be difficult.  In view of such integration, you might want to start
clearing copyright issues ASAP though (that is, signing FSF papers
for Automake contributions).

> But basically,
> as long as Automake's installation of Python libraries is working fine
> (installing to $(pkgpythondir)), it should be straight-forward. I'll
> test it out soon to see how it goes.
> 
> For those who aren't familiar with it, the purpose of Pyconfigure is to
> provide a useful set of template files for Python developers to
> integrate into their own projects to facilitate using the standard GNU
> configure/install procedure. This can be done alongside an existing
> setup.py file or, eventually, instead of one if you want. Pyconfigure's
> Python macros are generally adapted from the ones included in Automake,
> plus a few that I wrote. So, old configure.ac scripts probably wouldn't
> need too much adaptation to use them. You can see the code here:
> 
> http://git.savannah.gnu.org/cgit/pyconfigure.git/tree/
> (the templates are in the src/ directory)
> 
> I gladly welcome any comments, suggestions, patches, etc.! I have the
> mailing list bug-pyconfigure@HIDDEN (currently requires subscription
> or manual approval by me due to overwhelming spam), as CCed in this
> email, where you can contact me.
> 
> Thanks Stefano for bringing this conversation to my attention!
>
Thanks to you for starting that project, and for your quick feedback.

Best regards,
  Stefano

Message sent to bug-automake@HIDDEN:

Subject: bug#13170: automake and pyconfigure: a future integration?
Resent-From: Stefano Lattarini <stefano.lattarini@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Thu, 13 Dec 2012 15:00:02 +0000
Resent-Message-ID: <handler.13170.B.13554107896019 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Brandon Invergo <brandon@HIDDEN>
Cc: 13170 <at> debbugs.gnu.org, bug-pyconfigure@HIDDEN, jack@HIDDEN, automake-patches@HIDDEN, mail@HIDDEN
Message-ID: <50C9ED09.3030302@HIDDEN>
Date: Thu, 13 Dec 2012 15:58:17 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
	<87k3smt7f3.fsf@HIDDEN> <50C9DEE6.9050102@HIDDEN>
	<87bodyt4xz.fsf@HIDDEN>
In-Reply-To: <87bodyt4xz.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

On 12/13/2012 03:14 PM, Brandon Invergo wrote:
>>> What happens in pyconfigure (more on that in a moment) is that you can
>>> pass an argument to AC_PROG_PYTHON. So if you want to use Python 2
>>> specifically, you first search for it with AC_PROG_PYTHON([python2]).
>>> In a standard system, this should find the most recent Python 2
>>> interpreter.
>>>
>> Would that also find a python 2.x interpreter names simply as "python"?
> 
> No, it would just look for one called python2. That said, I guess
> there's nothing stopping you from doing AC_PROG_PYTHON([python2
> python]). Or, if you know you only want Python 2.5, 2.6 or 2.7:
> AC_PROG_PYTHON([python2 python2.7 python2.6 python2.5 python]). You can
> pass whatever arguments you want and it should work. No need to rewrite
> the macro (as this proposed patch in discussion apparently did).
> 
>>> Here's an example configure.ac chunk to do that using Pyconfigure's
>>> macros: 
>>>
>>>     m4_define(python_min_ver, 2.5)
>>>
>> (Nit: missing quotes; should be "m4_define([python_min_ver], [2.5])")
>> More important, you define this as a m4 macro ...
>> ... but later use it a shell variable.  What am I missing?
> 
> Heh...actually, in the code there's no $ since it's a macro...I added
> the $ as I was typing my email because I guess my head is in shell mode
> right now and it looked wrong. Anyway, mentally erase that $...it's not
> there :)
> 
> Thanks for the heads up on the quotes though; I'll fix that in my
> examples. 
> 
>> Note that for "integration" I didn't mean merging your project into
>> Automake, but rather, having Automake leveraging on the m4 macros
>> provided by it; as we do with, say, the 'LT_INIT' libtool-provided
>> macro, without needing nor wanting it to be part of the Automake
>> core.
> 
> Got it. Let's say "interoperation". I agree. I picture Pyconfigure as
> sort of boilerplate Autoconf & Automake glue for Python projects. The
> upstream projects do what they do best, and I figure out how to make
> them as effortless as possible to use with Python.
>
Glad we agree on this.

> That said, the macros
> should still be merged into Autoconf eventually so that people don't
> *need* to depend on Pyconfigure as well if they don't want to.
>
The nice thing is that such an integration would be mostly transparent
to Automake in any case :-)

>> I think that would go more smoothly collaborating with the upstreams
>> from the beginning; for example, we had some tweaks and bug-fixes
>> related to python support in Automake (see in particular the commits
>> v1.12.4-43-ge0e99ed and v1.12.5-14-g1f113f6 in the Automake's git
>> repository), and you might want to backport some of them into
>> pyconfigure as well.
> 
> That's a good point. I'll check out those commits when I get home this
> evening. What would be the best way for me to stay abreast of relevant
> Python-oriented Automake changes? Which mailing list? bug-automake?
>
That, and automake-patches.  But consider that the percentage of
python-related patches and reports there is reeeealy low.  Maybe
it's simpler if I just CC you and bug-pyconfigure in my replies
to any python-related message on the Automake lists (and hope I
won't forgot doing so).

>> Well, at least those parts of Automake deals with python ;-)
>>
>> And I'm open to such a rewrite, it it will brings clear advantages;
>>
Er, s/it it/if it/ and s/brings/bring/.  Sorry for the sloppiness.

>> e.g., better integration/compatibility with distutils, setuptools
>> and/or distribute (or what the python distribution subsystem du-jour
>> is, sigh), clearer semantics, etc.
>> No worry, once you have working rules, integrating them shouldn't
>> be difficult.  In view of such integration, you might want to start
>> clearing copyright issues ASAP though (that is, signing FSF papers
>> for Automake contributions).
> 
> Ok, well, I haven't even begun to tackle that part yet but I'll keep you
> guys informed of my progress.
> 
Thanks,
  Stefano

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#13170: automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)
Resent-From: Brandon Invergo <brandon@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Thu, 13 Dec 2012 16:58:02 +0000
Resent-Message-ID: <handler.13170.B.135541784120557 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 13170
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: patch
To: Stefano Lattarini <stefano.lattarini@HIDDEN>, Jack Kelly <jack@HIDDEN>
Cc: 13170 <at> debbugs.gnu.org, mail@HIDDEN, automake-patches@HIDDEN, bug-pyconfigure@HIDDEN
X-Debbugs-Original-Cc: bug-automake@HIDDEN, Kerrick Staley <mail@HIDDEN>, automake-patches@HIDDEN, bug-pyconfigure@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.135541784120557
          (code B ref -1); Thu, 13 Dec 2012 16:58:02 +0000
Received: (at submit) by debbugs.gnu.org; 13 Dec 2012 16:57:21 +0000
Received: from localhost ([127.0.0.1]:41148 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TjC62-0005LN-L8
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 11:57:21 -0500
Received: from eggs.gnu.org ([208.118.235.92]:56211)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <brandon@HIDDEN>) id 1Tj8q2-00075d-91
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 08:28:36 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1Tj8pA-0004KP-DZ
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 08:27:41 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE,
	T_DKIM_INVALID,USER_IN_WHITELIST autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:39447)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1Tj8pA-0004KK-AQ
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 08:27:40 -0500
Received: from eggs.gnu.org ([208.118.235.92]:39318)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1Tj8p5-0002Cc-ON
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 08:27:38 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1Tj8p4-0004Jc-7M
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 08:27:35 -0500
Received: from caiajhbdcahe.dreamhost.com ([208.97.132.74]:43440
	helo=homiemail-a25.g.dreamhost.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>)
	id 1Tj8ow-0004GT-Gn; Thu, 13 Dec 2012 08:27:26 -0500
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id A9E8E678063;
	Thu, 13 Dec 2012 05:27:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=invergo.net; h=from:to:cc
	:subject:in-reply-to:references:date:message-id:mime-version:
	content-type; s=invergo.net; bh=pllWLWUZicZZw3yDykvz70xWvAo=; b=
	rwXOWTdxlDXQ5C2UpqX4VJLM1T5SadgZk/jxQcKsXDzcpKID29HtggqqyEF7qcm1
	iG9DqrjRD6WBkirE3USo4d5ZDO/KrZoz9PEqa6dLtbkSWLYvHdf+6GdSV6OTz0Gm
	XI+CsafEvRV4cI0kN/E72REppBZjKyHwr7gO39d6+tQ=
Received: from localhost (nat-cmprbb-upf.upf.edu [193.145.39.133])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: brandon@HIDDEN)
	by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id D1CAD678058; 
	Thu, 13 Dec 2012 05:27:23 -0800 (PST)
From: Brandon Invergo <brandon@HIDDEN>
In-Reply-To: <50C9D003.4050702@HIDDEN>
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
User-Agent: Notmuch/0.14 (http://notmuchmail.org) Emacs/24.2.1
	(x86_64-unknown-linux-gnu)
Date: Thu, 13 Dec 2012 14:20:48 +0100
Message-ID: <87k3smt7f3.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -4.2 (----)
X-Mailman-Approved-At: Thu, 13 Dec 2012 11:57:17 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)

>>
> Me too, mostly.  But I agree that there is an underlying issue (albeit
> not major).
>
>> The "Future Changes to this Recommendation"
>> section of PEP 394 anticipates changing the `python' symlink to
>> `python3' at some point in the future.

This has already happened in Parabola, Arch and other similar distros. I
think it's best, with an eye to the future, to keep python3 at the front
of searches.

>>
>> I think a better patch would change the search list based on the major
>> version passed as the first argument to AM_PATH_PYTHON:
>> a) If it's 2.x, search `python2 python2.7 python2.6 ... python'.
>> b) If it's 3.x, search `python3 python3.3 python3.2 python3.1 ... python'.
>> c) If nothing's given, search `python python2 python2.7 ... python2.0
>>    python3 python3.2 ... python3.0.'
>> 
>> In case (c), swap the search order to search python3 interpreters first
>> once PEP 394 updates its recommendation to make python symlink to a
>> python 3 interpreter.
>>
> This sounds quite complex; too much, honestly.

What happens in pyconfigure (more on that in a moment) is that you can
pass an argument to AC_PROG_PYTHON. So if you want to use Python 2
specifically, you first search for it with AC_PROG_PYTHON([python2]). In
a standard system, this should find the most recent Python 2
interpreter. If it doesn't find anything, then do AC_PROG_PYTHON without
an argument to search the full list. If a Python 3 interpreter is found,
then that likely means that `python' in PATH refers to Python 3 and that
if Python 2 *is* installed, it's installed in some weird, non-standard
way. In that case, the user can always pass in the PYTHON env variable
as an argument to configure.

Here's an example configure.ac chunk to do that using Pyconfigure's
macros: 

    m4_define(python_min_ver, 2.5)
    AC_PROG_PYTHON([python2])
    if [[ "x$PYTHON" == "x" ]]; then
       AC_PROG_PYTHON
       PC_PYTHON_VERIFY_VERSION(3.0, ,
           AC_MSG_ERROR(Python 2 ($python_min_ver+) is required))
    fi

>
> What is more important, I don't think we should work on, tweak, nor
> improve AM_PATH_PYTHON anymore.  In fact, there is a new GNU project
> that aims at providing better autoconfigry integration for python:
>
>     <https://www.gnu.org/software/pyconfigure/>
>
> So I think that, instead of adding new code and semantics to automake,
> we should work toward improving that package, and integrate with it
> once it's mature enough (then we could deprecate, and some time in
> the future remove, the AM_PATH_PYTHON macro from automake).
>
> I've added the bug-pyconfigure in CC: to contact the author of that
> package, and hear his opinion on the matter.  Maybe we can start
> sketching out a roadmap and a TODO list ...

I know that I have not yet communicated with the Auto{make,conf} devs
enough about integrating the pyconfigure files upstream. Needless to
say, it's easiest for me to work on them and tweak them from the comfort
of a project that I maintain. So, I'm waiting until I get all the bugs
and kinks (like version checking) worked out so that they require as
little further work as possible upstream. 

Currently there is Python stuff spread out between Autoconf-archive,
Automake, and now Pyconfigure. I'm hoping to integrate the core of that
functionality into a robust set of macros in Pyconfigure (obviously some
specialized things can/should stay in autoconf-archive). I think these
core macros will be most appropriately integrated into Autoconf, since I
have implemented Python as an AC_LANG.

Future integration with Automake will be necessary. This is a bit of a
hand-wavy explanation but here it goes: currently Pyconfigure provides a
standard-GNU-style wrapper around Python's distutils setup.py; the next
step is to also offer the reverse, meaning a setup.py that essentially
calls the standard GNU stuff. Since Pyconfigure is all about making
things as easy as possible for maintaining these different build
procedures, very way that I think about it, I realize
that I would be largely rewriting Automake. What I will do is start to
implement it very manually in the Makefile.in and once I have a clear
idea of my needs, I'll bring it to you guys to see how we can implement
it (sadly, I don't know the inner workings of Automake). But basically,
as long as Automake's installation of Python libraries is working fine
(installing to $(pkgpythondir)), it should be straight-forward. I'll
test it out soon to see how it goes.

For those who aren't familiar with it, the purpose of Pyconfigure is to
provide a useful set of template files for Python developers to
integrate into their own projects to facilitate using the standard GNU
configure/install procedure. This can be done alongside an existing
setup.py file or, eventually, instead of one if you want. Pyconfigure's
Python macros are generally adapted from the ones included in Automake,
plus a few that I wrote. So, old configure.ac scripts probably wouldn't
need too much adaptation to use them. You can see the code here:

http://git.savannah.gnu.org/cgit/pyconfigure.git/tree/
(the templates are in the src/ directory)

I gladly welcome any comments, suggestions, patches, etc.! I have the
mailing list bug-pyconfigure@HIDDEN (currently requires subscription
or manual approval by me due to overwhelming spam), as CCed in this
email, where you can contact me.

Thanks Stefano for bringing this conversation to my attention!

Cheers,
Brandon

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#13170: automake and pyconfigure: a future integration?
Resent-From: Brandon Invergo <brandon@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Thu, 13 Dec 2012 16:58:02 +0000
Resent-Message-ID: <handler.13170.B.135541784220563 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 13170
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: patch
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Cc: 13170 <at> debbugs.gnu.org, bug-pyconfigure@HIDDEN, jack@HIDDEN, automake-patches@HIDDEN, mail@HIDDEN
X-Debbugs-Original-Cc: bug-automake@HIDDEN, bug-pyconfigure@HIDDEN, Jack Kelly <jack@HIDDEN>, automake-patches@HIDDEN, Kerrick Staley <mail@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.135541784220563
          (code B ref -1); Thu, 13 Dec 2012 16:58:02 +0000
Received: (at submit) by debbugs.gnu.org; 13 Dec 2012 16:57:22 +0000
Received: from localhost ([127.0.0.1]:41150 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TjC65-0005LX-9o
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 11:57:22 -0500
Received: from eggs.gnu.org ([208.118.235.92]:41441)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <brandon@HIDDEN>) id 1Tj9g1-0000ML-6G
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 09:22:18 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1Tj9f3-0001ME-65
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 09:21:24 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE,
	T_DKIM_INVALID,USER_IN_WHITELIST autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:43384)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1Tj9f3-0001MA-2z
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 09:21:17 -0500
Received: from eggs.gnu.org ([208.118.235.92]:52754)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1Tj9es-0001lQ-Fu
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 09:21:17 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1Tj9eo-0001KY-5e
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 09:21:06 -0500
Received: from caiajhbdccac.dreamhost.com ([208.97.132.202]:43879
	helo=homiemail-a34.g.dreamhost.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>)
	id 1Tj9ee-0001JR-B5; Thu, 13 Dec 2012 09:20:52 -0500
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 2ED2010062;
	Thu, 13 Dec 2012 06:20:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=invergo.net; h=from:to:cc
	:subject:in-reply-to:references:date:message-id:mime-version:
	content-type; s=invergo.net; bh=Y9RyN49h1VfIjhyUXo0A3zWNmXk=; b=
	nLvK2DjmWBv1Rqh8z6xrQOvkUiyZHNq4hGfB6au6R7xePsoX7ALOb6wgTzd85Un3
	DgQBSu050Ejca7ytkZAWSwm2HlH3tp9NROri81cMzx5+m0pEMRVZyg4DAQEmYQua
	XII2ac6nfdo66OEWzfLwDmW2eVMBF1wxhz5juAaPtKU=
Received: from localhost (nat-cmprbb-upf.upf.edu [193.145.39.133])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: brandon@HIDDEN)
	by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 552461001C; 
	Thu, 13 Dec 2012 06:20:50 -0800 (PST)
From: Brandon Invergo <brandon@HIDDEN>
In-Reply-To: <50C9DEE6.9050102@HIDDEN>
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
	<87k3smt7f3.fsf@HIDDEN> <50C9DEE6.9050102@HIDDEN>
User-Agent: Notmuch/0.14 (http://notmuchmail.org) Emacs/24.2.1
	(x86_64-unknown-linux-gnu)
Date: Thu, 13 Dec 2012 15:14:16 +0100
Message-ID: <87bodyt4xz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no
	timestamps) [generic] [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -4.2 (----)
X-Mailman-Approved-At: Thu, 13 Dec 2012 11:57:17 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)

>> What happens in pyconfigure (more on that in a moment) is that you can
>> pass an argument to AC_PROG_PYTHON. So if you want to use Python 2
>> specifically, you first search for it with AC_PROG_PYTHON([python2]).
>> In a standard system, this should find the most recent Python 2
>> interpreter.
>>
> Would that also find a python 2.x interpreter names simply as "python"?

No, it would just look for one called python2. That said, I guess
there's nothing stopping you from doing AC_PROG_PYTHON([python2
python]). Or, if you know you only want Python 2.5, 2.6 or 2.7:
AC_PROG_PYTHON([python2 python2.7 python2.6 python2.5 python]). You can
pass whatever arguments you want and it should work. No need to rewrite
the macro (as this proposed patch in discussion apparently did).

>> Here's an example configure.ac chunk to do that using Pyconfigure's
>> macros: 
>> 
>>     m4_define(python_min_ver, 2.5)
>>
> (Nit: missing quotes; should be "m4_define([python_min_ver], [2.5])")
> More important, you define this as a m4 macro ...
> ... but later use it a shell variable.  What am I missing?

Heh...actually, in the code there's no $ since it's a macro...I added
the $ as I was typing my email because I guess my head is in shell mode
right now and it looked wrong. Anyway, mentally erase that $...it's not
there :)

Thanks for the heads up on the quotes though; I'll fix that in my
examples. 

> Note that for "integration" I didn't mean merging your project into
> Automake, but rather, having Automake leveraging on the m4 macros
> provided by it; as we do with, say, the 'LT_INIT' libtool-provided
> macro, without needing nor wanting it to be part of the Automake
> core.

Got it. Let's say "interoperation". I agree. I picture Pyconfigure as
sort of boilerplate Autoconf & Automake glue for Python projects. The
upstream projects do what they do best, and I figure out how to make
them as effortless as possible to use with Python. That said, the macros
should still be merged into Autoconf eventually so that people don't
*need* to depend on Pyconfigure as well if they don't want to.

> I think that would go more smoothly collaborating with the upstreams
> from the beginning; for example, we had some tweaks and bug-fixes
> related to python support in Automake (see in particular the commits
> v1.12.4-43-ge0e99ed and v1.12.5-14-g1f113f6 in the Automake's git
> repository), and you might want to backport some of them into
> pyconfigure as well.

That's a good point. I'll check out those commits when I get home this
evening. What would be the best way for me to stay abreast of relevant
Python-oriented Automake changes? Which mailing list? bug-automake?

> Well, at least those parts of Automake deals with python ;-)
>
> And I'm open to such a rewrite, it it will brings clear advantages;
> e.g., better integration/compatibility with distutils, setuptools
> and/or distribute (or what the python distribution subsystem du-jour
> is, sigh), clearer semantics, etc.
> No worry, once you have working rules, integrating them shouldn't
> be difficult.  In view of such integration, you might want to start
> clearing copyright issues ASAP though (that is, signing FSF papers
> for Automake contributions).

Ok, well, I haven't even begun to tackle that part yet but I'll keep you
guys informed of my progress.

Cheers,
Brandon

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#13170: automake and pyconfigure: a future integration?
Resent-From: Brandon Invergo <brandon@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Thu, 13 Dec 2012 19:49:01 +0000
Resent-Message-ID: <handler.13170.B.13554281008372 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 13170
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: patch
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Cc: 13170 <at> debbugs.gnu.org, bug-pyconfigure@HIDDEN
X-Debbugs-Original-Cc: bug-automake@HIDDEN, bug-pyconfigure@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.13554281008372
          (code B ref -1); Thu, 13 Dec 2012 19:49:01 +0000
Received: (at submit) by debbugs.gnu.org; 13 Dec 2012 19:48:20 +0000
Received: from localhost ([127.0.0.1]:41294 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TjElX-0002Az-PK
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 14:48:20 -0500
Received: from eggs.gnu.org ([208.118.235.92]:55393)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <brandon@HIDDEN>) id 1TjElV-0002Ao-4m
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 14:48:17 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1TjEkc-00089j-Qn
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 14:47:23 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE,
	USER_IN_WHITELIST autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:55372)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1TjEkc-00089a-OC
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 14:47:22 -0500
Received: from eggs.gnu.org ([208.118.235.92]:38520)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1TjEkb-0004hG-Qe
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 14:47:22 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <brandon@HIDDEN>) id 1TjEkY-00089A-CP
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 14:47:21 -0500
Received: from hapkido.dreamhost.com ([66.33.216.122]:34484)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <brandon@HIDDEN>)
	id 1TjEkY-00088z-6c; Thu, 13 Dec 2012 14:47:18 -0500
Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaib.dreamhost.com
	[208.97.132.81])
	by hapkido.dreamhost.com (Postfix) with ESMTP id 1C3533FBF35;
	Thu, 13 Dec 2012 11:47:17 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id CC1A6428086;
	Thu, 13 Dec 2012 11:47:14 -0800 (PST)
Received: from localhost (unknown [95.61.26.193])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: brandon@HIDDEN)
	by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 2E4004280A4; 
	Thu, 13 Dec 2012 11:46:27 -0800 (PST)
From: Brandon Invergo <brandon@HIDDEN>
In-Reply-To: <50C9DEE6.9050102@HIDDEN>
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
	<87k3smt7f3.fsf@HIDDEN> <50C9DEE6.9050102@HIDDEN>
User-Agent: Notmuch/0.14 (http://notmuchmail.org) Emacs/24.2.1
	(x86_64-unknown-linux-gnu)
Date: Thu, 13 Dec 2012 20:46:22 +0100
Message-ID: <87r4mtloq9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -4.2 (----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -4.2 (----)

> I think that would go more smoothly collaborating with the upstreams
> from the beginning; for example, we had some tweaks and bug-fixes
> related to python support in Automake (see in particular the commits
> v1.12.4-43-ge0e99ed and v1.12.5-14-g1f113f6 in the Automake's git
> repository), and you might want to backport some of them into
> pyconfigure as well.

Thanks for the heads-up on these; I've integrated them in Pyconfigure.

BTW, in response to your other email, CC'ing me is fine when there are
relevant Python changes if you remember. 

Thanks again!
brandon

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#13170: automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)
Resent-From: Kerrick Staley <mail@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Fri, 14 Dec 2012 00:13:02 +0000
Resent-Message-ID: <handler.13170.B.135544392710113 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 13170
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: patch
To: Brandon Invergo <brandon@HIDDEN>
Cc: 13170 <at> debbugs.gnu.org, stefano.lattarini@HIDDEN, jack@HIDDEN, automake-patches@HIDDEN, bug-pyconfigure@HIDDEN
X-Debbugs-Original-Cc: bug-automake@HIDDEN, Stefano Lattarini <stefano.lattarini@HIDDEN>, Jack Kelly <jack@HIDDEN>, automake-patches@HIDDEN, bug-pyconfigure@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.135544392710113
          (code B ref -1); Fri, 14 Dec 2012 00:13:02 +0000
Received: (at submit) by debbugs.gnu.org; 14 Dec 2012 00:12:07 +0000
Received: from localhost ([127.0.0.1]:41487 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TjIsl-0002cu-Cf
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 19:12:07 -0500
Received: from eggs.gnu.org ([208.118.235.92]:46054)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <mail@HIDDEN>) id 1TjIjR-0002Hm-B4
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 19:02:30 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mail@HIDDEN>) id 1TjIiU-0003nb-52
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 19:01:30 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW, USER_IN_WHITELIST autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:45646)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mail@HIDDEN>) id 1TjIiU-0003nX-1z
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2012 19:01:26 -0500
Received: from eggs.gnu.org ([208.118.235.92]:57380)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mail@HIDDEN>) id 1TjIiP-0000oT-3i
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 19:01:25 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mail@HIDDEN>) id 1TjIiK-0003mo-8k
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 19:01:21 -0500
Received: from mail-ie0-f169.google.com ([209.85.223.169]:37474)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mail@HIDDEN>) id 1TjIiK-0003mV-3n
	for bug-automake@HIDDEN; Thu, 13 Dec 2012 19:01:16 -0500
Received: by mail-ie0-f169.google.com with SMTP id c14so5161633ieb.0
	for <bug-automake@HIDDEN>; Thu, 13 Dec 2012 16:01:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=xWIIQt7KwFPS7v08CvQQgMGvPF/LKF1o7MGtbE2cgbo=;
	b=mkST45mVpPFY2/vhPZ5IU5JykO7XrtVDvBg04Br5kkmZjpSH27H44amt4WW8K14OTM
	E5sgJ+nSqriueyS3zOBa2NJj5cBmS7gDiPbKoKjYHdKgiY5muFEFUSYJoxgqqY2YYz55
	Inq/FV20Uj9r70Yfo3dmgY8bxK4zqapkgWDbS+Th/o9PuFALpFb/IvEtkMShvbOPwuTz
	9iEiIj+1iYQov2dt+W8vvVJiiTVpbT76cwHOC2atOboFQgI73gke7dIhsFMoW+T16pIs
	ZdBv1ixv4IvGfJv3bd8c8jv2lhQ3+WrkTdD3shXyMX+t5h0Wsy+pWUpZ5eaScfMt0IwX
	7PaQ==
Received: by 10.42.101.144 with SMTP id e16mr3180998ico.5.1355443274958;
	Thu, 13 Dec 2012 16:01:14 -0800 (PST)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com
	[209.85.223.169])
	by mx.google.com with ESMTPS id i9sm5505142igl.9.2012.12.13.16.01.13
	(version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 16:01:13 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id c14so5161592ieb.0
	for <bug-automake@HIDDEN>; Thu, 13 Dec 2012 16:01:12 -0800 (PST)
Received: by 10.50.53.147 with SMTP id b19mr45904igp.12.1355443272345; Thu, 13
	Dec 2012 16:01:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.81.12 with HTTP; Thu, 13 Dec 2012 16:00:52 -0800 (PST)
X-Originating-IP: [65.110.227.43]
In-Reply-To: <87k3smt7f3.fsf@HIDDEN>
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
	<87k3smt7f3.fsf@HIDDEN>
From: Kerrick Staley <mail@HIDDEN>
Date: Thu, 13 Dec 2012 18:00:52 -0600
Message-ID: <CANaWP3yDp27eJSAV5uaGw06guWKG_1v8v4u89gdRHb9AXQOJ9g@HIDDEN>
Content-Type: multipart/alternative; boundary=f46d04339c96c2e6fc04d0c4ba67
X-Gm-Message-State: ALoCoQmc4nUWF1k+ZncbBLc2/dLM8CCXS5mojc5t0kOQfnPDI2kfsoZp9c4+HkVlsN2mXB3mQ+3i
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -4.2 (----)
X-Mailman-Approved-At: Thu, 13 Dec 2012 19:12:01 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -5.0 (-----)

--f46d04339c96c2e6fc04d0c4ba67
Content-Type: text/plain; charset=ISO-8859-1

Quite a lengthy response for such a simple inquiry!

Really, I'd just like to get gobject-introspection to compile on Arch
Linux. The problem is that gobject-introspection's configure.ac has the line

AM_PATH_PYTHON([2.5])

but gobject-introspection can't actually work with Python 3 or higher (the
default on Arch); it needs Python 2. Automake doesn't seem to provide a way
to specify this need.

The problem could be fixed by changing AM_PATH_PYTHON could be changed to
prefer Python 2 over Python 3, as my patch does. However, I guess this
would cause packages that support both Python 2 and Python 3 to build
against Python 2 by default even if Python 3 is present.

Pyconfigure looks like the best way forward, then, but it's not widely
deployed at this point. AM_PATH_PYTHON could also just be tweaked to
support a "max version" argument. I'm passing PYTHON=/usr/bin/python2 to
autogen.sh for the time being.

- Kerrick

--f46d04339c96c2e6fc04d0c4ba67
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Quite a lengthy response for such a simple inquiry!<div><br></div><div>Real=
ly, I&#39;d just like to get gobject-introspection to compile on Arch Linux=
. The problem is that gobject-introspection&#39;s <a href=3D"http://configu=
re.ac">configure.ac</a> has the line</div>

<div><br></div><div>AM_PATH_PYTHON([2.5])</div><div><br></div><div>but gobj=
ect-introspection can&#39;t actually work with Python 3 or higher (the defa=
ult on Arch); it needs Python 2. Automake doesn&#39;t seem to provide a way=
 to specify this need.</div>

<div><br></div><div>The problem could be fixed by changing AM_PATH_PYTHON c=
ould be changed to prefer Python 2 over Python 3, as my patch does. However=
, I guess this would cause packages that support both Python 2 and Python 3=
 to build against Python 2 by default even if Python 3 is present.</div>

<div><br></div><div>Pyconfigure looks like the best way forward, then, but =
it&#39;s not widely deployed at this point. AM_PATH_PYTHON could also just =
be tweaked to support a &quot;max version&quot; argument. I&#39;m passing P=
YTHON=3D/usr/bin/python2 to autogen.sh for the time being.</div>

<div><br></div><div>- Kerrick</div><br>

--f46d04339c96c2e6fc04d0c4ba67--

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#13170: automake and pyconfigure: a future integration?
Resent-From: Stefano Lattarini <stefano.lattarini@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Fri, 14 Dec 2012 08:38:01 +0000
Resent-Message-ID: <handler.13170.B.13554742398699 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 13170
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: patch
To: Kerrick Staley <mail@HIDDEN>
Cc: brandon@HIDDEN, 13170 <at> debbugs.gnu.org, jack@HIDDEN, automake-patches@HIDDEN, bug-pyconfigure@HIDDEN
X-Debbugs-Original-Cc: Brandon Invergo <brandon@HIDDEN>, bug-automake@HIDDEN, Jack Kelly <jack@HIDDEN>, automake-patches@HIDDEN, bug-pyconfigure@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.13554742398699
          (code B ref -1); Fri, 14 Dec 2012 08:38:01 +0000
Received: (at submit) by debbugs.gnu.org; 14 Dec 2012 08:37:19 +0000
Received: from localhost ([127.0.0.1]:41841 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TjQli-0002GF-F2
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 03:37:18 -0500
Received: from eggs.gnu.org ([208.118.235.92]:55477)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <stefano.lattarini@HIDDEN>) id 1TjQlg-0002G8-1D
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 03:37:17 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefano.lattarini@HIDDEN>) id 1TjQkj-0005Pq-W8
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 03:36:19 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_LOW, T_DKIM_INVALID,
	USER_IN_WHITELIST autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:35792)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefano.lattarini@HIDDEN>) id 1TjQkj-0005Pm-TO
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 03:36:17 -0500
Received: from eggs.gnu.org ([208.118.235.92]:38604)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefano.lattarini@HIDDEN>) id 1TjQki-0000ya-FM
	for bug-automake@HIDDEN; Fri, 14 Dec 2012 03:36:17 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefano.lattarini@HIDDEN>) id 1TjQkg-0005P9-8f
	for bug-automake@HIDDEN; Fri, 14 Dec 2012 03:36:16 -0500
Received: from mail-bk0-f41.google.com ([209.85.214.41]:61906)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefano.lattarini@HIDDEN>)
	id 1TjQkZ-0005NX-27; Fri, 14 Dec 2012 03:36:07 -0500
Received: by mail-bk0-f41.google.com with SMTP id jg9so1489145bkc.0
	for <multiple recipients>; Fri, 14 Dec 2012 00:36:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=hpzwoVXmlNfuleHchZLQs5eh0mau+lAcDZ+0mkLRzLM=;
	b=cyZVSTR37a2S7SiTOzOvMqWqPBRoie7QkTG+bs1g0ZfWoqlkXW+F578E+kvxc/NAax
	0ngUlxeKEbnOyib93YyZ5R9W4ocQHVORy+4f83n+8Q6fE2/j5D9fKu7v07+fORsOHf6e
	CbjanREPn6ecJtFdWkArEAfY8XpiZtzGjgKJQx/vzins7XY+oC+TMf/J8qEc3fUpKTvr
	3dkFpo+W1/X33KeN+kKyQJBJ+lXIMiqTSqCevANdrPkzoCT9bLDyVdvgISRumdhK6o9b
	L/zgXBUdcRE5pn9MBudxYBnKSQyoQe3Kd+c3/iaLo55MnpoEdaoT3TYBMJYoNiDnkAtP
	L3UA==
Received: by 10.205.139.16 with SMTP id iu16mr2421800bkc.88.1355474165153;
	Fri, 14 Dec 2012 00:36:05 -0800 (PST)
Received: from [192.168.178.21]
	(host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137])
	by mx.google.com with ESMTPS id o9sm3456242bko.15.2012.12.14.00.36.03
	(version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 00:36:04 -0800 (PST)
Message-ID: <50CAE4F2.6030809@HIDDEN>
Date: Fri, 14 Dec 2012 09:36:02 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
	<87k3smt7f3.fsf@HIDDEN>
	<CANaWP3yDp27eJSAV5uaGw06guWKG_1v8v4u89gdRHb9AXQOJ9g@HIDDEN>
In-Reply-To: <CANaWP3yDp27eJSAV5uaGw06guWKG_1v8v4u89gdRHb9AXQOJ9g@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -3.4 (---)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -4.2 (----)

On 12/14/2012 01:00 AM, Kerrick Staley wrote:
> Quite a lengthy response for such a simple inquiry!
> 
> Really, I'd just like to get gobject-introspection to compile on Arch
> Linux. The problem is that gobject-introspection's configure.ac has the line
> 
> AM_PATH_PYTHON([2.5])
> 
> but gobject-introspection can't actually work with Python 3 or higher (the
> default on Arch); it needs Python 2. Automake doesn't seem to provide a way
> to specify this need.
> 
> The problem could be fixed by changing AM_PATH_PYTHON could be changed to
> prefer Python 2 over Python 3, as my patch does. However, I guess this
> would cause packages that support both Python 2 and Python 3 to build
> against Python 2 by default even if Python 3 is present.
>
> Pyconfigure looks like the best way forward, then, but it's not widely
> deployed at this point. AM_PATH_PYTHON could also just be tweaked to
> support a "max version" argument. I'm passing PYTHON=/usr/bin/python2 to
> autogen.sh for the time being.
> 
As another workaround, you might copy the Automake-provided python.m4 file
to a local m4 directory, apply your patch to this copy, and the ensure you
invoke aclocal with a '-I' option that will cause your patched copy to be
considered before the one bundled with Automake.

HTH,
  Stefano

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#13170: automake and pyconfigure: a future integration?
Resent-From: Jack Kelly <jack@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Fri, 14 Dec 2012 10:19:02 +0000
Resent-Message-ID: <handler.13170.B.135548029117520 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 13170
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: patch
To: Kerrick Staley <mail@HIDDEN>
Cc: 13170 <at> debbugs.gnu.org, brandon@HIDDEN, stefano.lattarini@HIDDEN, bug-pyconfigure@HIDDEN, automake-patches@HIDDEN
X-Debbugs-Original-Cc: bug-automake@HIDDEN, Brandon Invergo <brandon@HIDDEN>, Stefano Lattarini <stefano.lattarini@HIDDEN>, bug-pyconfigure@HIDDEN, automake-patches@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.135548029117520
          (code B ref -1); Fri, 14 Dec 2012 10:19:02 +0000
Received: (at submit) by debbugs.gnu.org; 14 Dec 2012 10:18:11 +0000
Received: from localhost ([127.0.0.1]:41905 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TjSLK-0004YX-Rs
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 05:18:11 -0500
Received: from eggs.gnu.org ([208.118.235.92]:49222)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <jack@HIDDEN>) id 1TjSLH-0004YP-UT
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 05:18:08 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jack@HIDDEN>) id 1TjSKL-0004Xg-71
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 05:17:10 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-101.1 required=5.0 tests=BAYES_00, DATE_IN_PAST_06_12,
	RCVD_IN_DNSWL_LOW,USER_IN_WHITELIST autolearn=no version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:48206)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jack@HIDDEN>) id 1TjSKL-0004Xb-41
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 05:17:09 -0500
Received: from eggs.gnu.org ([208.118.235.92]:60564)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jack@HIDDEN>) id 1TjSKJ-00079z-87
	for bug-automake@HIDDEN; Fri, 14 Dec 2012 05:17:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jack@HIDDEN>) id 1TjSKH-0004Wh-Tw
	for bug-automake@HIDDEN; Fri, 14 Dec 2012 05:17:07 -0500
Received: from mail-da0-f41.google.com ([209.85.210.41]:41757)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jack@HIDDEN>) id 1TjSKH-0004WJ-O0
	for bug-automake@HIDDEN; Fri, 14 Dec 2012 05:17:05 -0500
Received: by mail-da0-f41.google.com with SMTP id e20so1287399dak.0
	for <bug-automake@HIDDEN>; Fri, 14 Dec 2012 02:17:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:to:cc:subject:references:date:in-reply-to:message-id
	:user-agent:mime-version:content-type:x-gm-message-state;
	bh=OtatxRntnUdhoSSopFlbgnPb/DdG1aEuG718maaCpgA=;
	b=CYXIqWeKx15+GPHJ/MDnGRJaVosoxUk9xnWjNgbfY0jzX6mazc+QJSyQA8ie4Nbd24
	qO56CiPSR8APJVs7VaMULPKmoQCsPxqh/ms9QAMCU1TpEY3weIrWsVjQBAe4Osxblhs4
	XtYaSfUXk3HblUVSunELUyf3D01By1Fx5aeL1sI+eF4QVL/VRBHjON5Fh9Z4p+1AsCi0
	3UyOEi/EU4GXIqTeDDnQ4e4pNJSYTiALCm/DUjevQVZIODYinBOfBZEHE9/9ovAmQ1lF
	dUnbkbMcQvpXZALo2NGJYKPETPorQ8DMVMoEpAL6NgBqsS2BoTDFGxzo16RiYZVS6FaR
	Mmsw==
Received: by 10.68.247.134 with SMTP id ye6mr14304192pbc.69.1355480224713;
	Fri, 14 Dec 2012 02:17:04 -0800 (PST)
Received: from handybilly ([120.29.240.8])
	by mx.google.com with ESMTPS id s7sm2980595paz.7.2012.12.14.02.16.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 14 Dec 2012 02:17:03 -0800 (PST)
From: Jack Kelly <jack@HIDDEN>
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
	<87k3smt7f3.fsf@HIDDEN>
	<CANaWP3yDp27eJSAV5uaGw06guWKG_1v8v4u89gdRHb9AXQOJ9g@HIDDEN>
Date: Fri, 14 Dec 2012 13:10:59 +1100
In-Reply-To: <CANaWP3yDp27eJSAV5uaGw06guWKG_1v8v4u89gdRHb9AXQOJ9g@HIDDEN>
	(Kerrick Staley's message of "Thu, 13 Dec 2012 18:00:52 -0600")
Message-ID: <871uets7rg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Gm-Message-State: ALoCoQkcTmNxSquOlfiJuPNmyi8P6i/kWb5hq0YB2aKno3yQSiZt4newOovSMPOeHVcsmEaxU47U
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -2.7 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -4.0 (----)

Kerrick Staley <mail@HIDDEN> writes:

> Really, I'd just like to get gobject-introspection to compile on Arch Linux.
> The problem is that gobject-introspection's configure.ac has the line
>
> AM_PATH_PYTHON([2.5])
>
> but gobject-introspection can't actually work with Python 3 or higher (the
> default on Arch); it needs Python 2. Automake doesn't seem to provide a way to
> specify this need.

If you're just building gobject-introspection, then ./configure
PYTHON=/usr/bin/python2 is the way to go. If you're trying to fix
gobject-introspection, then perhaps the solutions offered at
http://stackoverflow.com/questions/4619664/autofoo-test-for-maximum-version-of-python
may help?

-- Jack

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#13170: automake and pyconfigure: a future integration?
Resent-From: Roumen Petrov <bugtrack@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sat, 15 Dec 2012 00:32:02 +0000
Resent-Message-ID: <handler.13170.B13170.13555315086547 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 13170
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: patch
To: 13170 <at> debbugs.gnu.org
Cc: Brandon Invergo <brandon@HIDDEN>, stefano.lattarini@HIDDEN, Kerrick Staley <mail@HIDDEN>, jack@HIDDEN
Received: via spool by 13170-submit <at> debbugs.gnu.org id=B13170.13555315086547
          (code B ref 13170); Sat, 15 Dec 2012 00:32:02 +0000
Received: (at 13170) by debbugs.gnu.org; 15 Dec 2012 00:31:48 +0000
Received: from localhost ([127.0.0.1]:43059 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TjffP-0001hX-Ec
	for submit <at> debbugs.gnu.org; Fri, 14 Dec 2012 19:31:47 -0500
Received: from rila.superhosting.bg ([91.196.124.212]:47760)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <bugtrack@HIDDEN>) id 1TjffM-0001hM-61
	for 13170 <at> debbugs.gnu.org; Fri, 14 Dec 2012 19:31:46 -0500
Received: from [78.128.48.21] (port=48143 helo=[192.168.0.10])
	by rila.superhosting.bg with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.80) (envelope-from <bugtrack@HIDDEN>)
	id 1TjfeK-003fYh-Hq; Sat, 15 Dec 2012 02:30:40 +0200
Message-ID: <50CBC4B0.3030006@HIDDEN>
Date: Sat, 15 Dec 2012 02:30:40 +0200
From: Roumen Petrov <bugtrack@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1
MIME-Version: 1.0
References: <1355388755-26689-1-git-send-email-mail@HIDDEN>
	<87vcc6s1f6.fsf@HIDDEN> <50C9D003.4050702@HIDDEN>
	<87k3smt7f3.fsf@HIDDEN>
	<CANaWP3yDp27eJSAV5uaGw06guWKG_1v8v4u89gdRHb9AXQOJ9g@HIDDEN>
In-Reply-To: <CANaWP3yDp27eJSAV5uaGw06guWKG_1v8v4u89gdRHb9AXQOJ9g@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - rila.superhosting.bg
X-AntiAbuse: Original Domain - debbugs.gnu.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roumenpetrov.info
X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id:
	master78@HIDDEN
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.8 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: 0.8 (/)

Hi All,

This is cross-list discussion and my post is only to ...@debbugs.gnu.org .

Kerrick Staley wrote:
> Quite a lengthy response for such a simple inquiry!
>
> Really, I'd just like to get gobject-introspection to compile on Arch
> Linux. The problem is that gobject-introspection's configure.ac has the line
>
> AM_PATH_PYTHON([2.5])
>
> but gobject-introspection can't actually work with Python 3 or higher (the
> default on Arch); it needs Python 2. Automake doesn't seem to provide a way
> to specify this need.

Probably exist package that could be run on 3x without to be ported.
May be automake macro could be improved to check for same 'major' version.


> The problem could be fixed by changing AM_PATH_PYTHON could be changed to
> prefer Python 2 over Python 3, as my patch does.
I don't know what is content of Kerrick's patch as I'm not subscriber of 
am.patch list.

AM-macro (11.x or master) use default list python python2 python3 
python3.x.... python2.7 ... python2.0.
Also 3.x lack search for cpython ABI versions but I could not found 
reasons macro to support this.

> However, I guess this
> would cause packages that support both Python 2 and Python 3 to build
> against Python 2 by default even if Python 3 is present.
I'm not sure that am-macro should check for X.Y versions. I think that 
python3 is enough . Lets keep in list 2.x for historical reasons.

CPython create hard link python ->  pythonX.Y for versions from 2x 
branches. Such link is not created in 3x branches . Those branches 
create link python3 -> python3.N (symbolic in more recent) and hard link 
python3.N -> python3.N$(ABI) . Only pyvenv does not follow such rule 
(symlinked to pyvenv-3.N) may be because does not exist in 2.x branch.

If a vendor decide to link python to python3 then 3x version will be 
preferred.

Also users could specify python interpreter in PYTHON env. variable same 
as CC end etc. This is the way that I test automake from master branch 
some time ago with cpython from head on site with 2.7.3 version.

$ PATH=$PY_ROOT/bin:$PATH
$ export PATH
$ PYTHON=python3.4
$ export PYTHON
$ cat python3.log
python3: running python3.4 -V
Python 3.4.0a0
....
checking for python version... 3.4
....
++ python3.4 -c 'import imp; print(imp.get_tag())'
+ am_pep3147_tag=cpython-34
....
python3: exit 0


Version in name is not available on windows where exists only python.exe 
(+pythonw.exe) but installations use different path.

[SNIP]

Roumen

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 3 Jan 2013 21:47:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 16:47:07 2013
Received: from localhost ([127.0.0.1]:42079 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Tqsd0-0001nF-Oi
	for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 16:47:07 -0500
Received: from mail-ee0-f52.google.com ([74.125.83.52]:52651)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <stefano.lattarini@HIDDEN>) id 1Tqscy-0001n4-Rh
	for control <at> debbugs.gnu.org; Thu, 03 Jan 2013 16:47:05 -0500
Received: by mail-ee0-f52.google.com with SMTP id d17so7637366eek.39
	for <control <at> debbugs.gnu.org>; Thu, 03 Jan 2013 13:47:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:message-id:date:from:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=VjleGshG0vCapJ/mFaxeSbJv6A4uzPu2U69D5fc5RVQ=;
	b=lm9LoeKyCwNyT2b3x230kTTHMZgZaqXIcRjCpfVdKIVfHXGlW2U3M0r5WPkHFfiynn
	/pZoavLvRCQqqPsZzIV/p3MaJ7I+KticzQB9Eyispmt0t1rxHi6aaYXQYEtBCztaNiV3
	eVEHz0hU+GRBbR6f85oR2oE5BX+D3Mvhk34yVnx1bwv0fwva+qprfnB/mLqnqr+oAbdq
	lVyw9TK/e2cVaG0DtsOKdhVqoMxJJC9tMzOSTpFimpng8YOIHTehKQ+VS+WSYD5cEC4D
	JQ0i1oruuO9pR7WLov/0x0HXT1xPidudRatY/7aC3pyvIBYbHT3y/nuZiGNfPQxeBiO8
	0MUA==
X-Received: by 10.14.213.134 with SMTP id a6mr137371187eep.45.1357249620945;
	Thu, 03 Jan 2013 13:47:00 -0800 (PST)
Received: from [192.168.178.21]
	(host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137])
	by mx.google.com with ESMTPS id l3sm106636742eem.14.2013.01.03.13.46.54
	(version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 13:47:00 -0800 (PST)
Message-ID: <50E5FC4C.3020605@HIDDEN>
Date: Thu, 03 Jan 2013 22:46:52 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: GNU bug tracker automated control server <control <at> debbugs.gnu.org>
Subject: 13170
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: 0.1 (/)

tags 13170 - patch
thanks

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.