GNU bug report logs - #13170
automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)

Previous Next

Full log

Message #32 received at 13170 <at> debbugs.gnu.org (full text, mbox):

From: Roumen Petrov <bugtrack <at> roumenpetrov.info>
To: 13170 <at> debbugs.gnu.org
Cc: Brandon Invergo <brandon <at> invergo.net>, stefano.lattarini <at> gmail.com,
	Kerrick Staley <mail <at> kerrickstaley.com>, jack <at> jackkelly.name
Subject: Re: bug#13170: automake and pyconfigure: a future integration?
Date: Sat, 15 Dec 2012 02:30:40 +0200

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

Previous Next

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