GNU bug report logs -
#13170
automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)
Previous Next
To reply to this bug, email your comments to 13170 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Thu, 13 Dec 2012 12:56:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefano Lattarini <stefano.lattarini <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org.
(Thu, 13 Dec 2012 12:56:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> kerrickstaley.com> 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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Thu, 13 Dec 2012 14:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> gnu.org (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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Thu, 13 Dec 2012 15:00:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Thu, 13 Dec 2012 16:58:02 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
>>
> 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 <at> gnu.org (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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Thu, 13 Dec 2012 16:58:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Thu, 13 Dec 2012 19:49:01 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Fri, 14 Dec 2012 00:13:02 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Fri, 14 Dec 2012 08:38:01 GMT)
Full text and
rfc822 format available.
Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Fri, 14 Dec 2012 10:19:02 GMT)
Full text and
rfc822 format available.
Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
Kerrick Staley <mail <at> kerrickstaley.com> 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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13170; Package
automake.
(Sat, 15 Dec 2012 00:32:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 13170 <at> debbugs.gnu.org (full text, mbox):
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
Removed tag(s) patch.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Thu, 03 Jan 2013 21:48:01 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 163 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.