GNU bug report logs - #17811
RFE: build against multiple python stacks

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Karl Berry <karl <at> freefriends.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#17811: closed (RFE: build against multiple python stacks)
Date: Mon, 24 Feb 2025 23:48:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 24 Feb 2025 16:46:30 -0700
with message-id <202502242346.51ONkUtO1124393 <at> freefriends.org>
and subject line Re: bug#17811: RFE: build against multiple python stacks
has caused the debbugs.gnu.org bug report #17811,
regarding RFE: build against multiple python stacks
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> 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)]

From: Pavel Raiskup <praiskup <at> redhat.com>
To: Automake Bugs <bug-automake <at> gnu.org>
Subject: RFE: build against multiple python stacks
Date: Thu, 19 Jun 2014 14:37:52 +0200

[Message part 3 (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)]

[Message part 6 (message/rfc822, inline)]

From: Karl Berry <karl <at> freefriends.org>
To: praiskup <at> redhat.com
Cc: 17811 <at> debbugs.gnu.org, 71672 <at> debbugs.gnu.org
Subject: Re: bug#17811: RFE: build against multiple python stacks
Date: Mon, 24 Feb 2025 16:46:30 -0700

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.

Previous Next

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