GNU bug report logs -
#17811
RFE: build against multiple python stacks
Previous Next
Reported by: Pavel Raiskup <praiskup <at> redhat.com>
Date: Thu, 19 Jun 2014 12:39:02 UTC
Severity: wishlist
Tags: confirmed
Done: Karl Berry <karl <at> freefriends.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#17811: RFE: build against multiple python stacks
which was filed against the automake package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 17811 <at> debbugs.gnu.org.
--
17811: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17811
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hi Pavel - back in 2014 (!), you suggested supporting python2 and python3
simultaneously: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17811
Essentially by defining a new "python3" primary to sit alongside
"python".
Agreed that this is desirable in general. It's now being discussed in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71672
via a somewhat different approach. I'd worry about making python3 a new
primary, since 3 vs. 2 is not the only distinction needed, as has been
discussed.
I'm closing this one to reduce duplication in the bugdb, but feel free
to reply on 71762 or open a new issue if desired. --thanks, karl.
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
Hello,
I have been playing a little with Python dual-stack build (as a PoC for
long-term filed issue against RH Bugzilla [1]).
Non-tl;dr version of task regarding this RFE:
There is need to build python plugins against both python2 & python3
with autotools easily.
Current status:
Automake supports python_PYTHON/pkgpython_PYTHON variable definition
which uses variables PYTHON/pythondir/pkgpythondir, etc. It caches the
results among multiple AM_PYTHON_PATH calls, etc. Works as expected in
usual cases.
To workaround problems with ${task}, e.g. abrt package handles this its
own way, see [2].
Proposed solution:
Make the _PYTHON primary support namespaces. PoC patch attached. This
allows us to work with python like:
configure.ac:
AM_PATH_PYTHON([2.7])
AM_PATH_PYTHON([3.3],,,3)
Makefile.am:
both_versions = main.py
python_PYTHON = $(both_versions)
python3_PYTHON = $(both_versions) python3_stuff.py
./configure | grep PYTHON
PYTHON the Python interpreter
PYTHON3 the Python3 interpreter
The fourth parameter of AM_PATH_PYTHON is not arbitrarily limited to
numbers or something like that (so we may use more than two python
stacks). The result of this macro is:
$ cat src/Makefile | grep -i ^python
PYTHON = /usr/bin/python
PYTHON3 = /usr/bin/python3
PYTHON3_EXEC_PREFIX = ${exec_prefix}
PYTHON3_PLATFORM = linux
PYTHON3_PREFIX = ${prefix}
...
python_PYTHON = main.py
python3_PYTHON = main2.py
What do you think about that? Could this be way to go? AM_PATH_PYTHON
would stay backward compatible, current testsuite is OK (log attached).
If that was OK, I would prepare more clean patch (not so much $4s in
python.m4 probably) with testsuite & documenation fixes.
[1] https://bugzilla.redhat.com/533920
[2] https://github.com/abrt/abrt/blob/master/configure.ac#L59
Pavel
[multi-python.patch (text/x-patch, attachment)]
[test-suite.log.xz (application/x-xz, attachment)]
This bug report was last modified 86 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.