Bug 533920 - RFC: (automake) add support for dual python 2 / python 3 builds
RFC: (automake) add support for dual python 2 / python 3 builds
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: automake (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Pavel Raiskup
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: Python3F13
  Show dependency treegraph
 
Reported: 2009-11-09 14:15 EST by Dave Malcolm
Modified: 2016-11-30 19:52 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Hacked up python3.m4, from python.m4, defining an AM_PATH_PYTHON3 (7.89 KB, text/plain)
2009-11-09 14:16 EST, Dave Malcolm
no flags Details
Example with double environments (3.56 KB, application/x-gzip)
2012-10-04 02:26 EDT, Pavel Raiskup
no flags Details

  None (edit)
Description Dave Malcolm 2009-11-09 14:15:06 EST
Description of problem:
/usr/share/aclocal-1.11/python.m4 contains a definition of 
AM_PATH_PYTHON which encapsulates the configuration magic for building an extension module against one version of python.

I'm working towards packaging a secondary Python 3 stack in Fedora (see  https://fedoraproject.org/wiki/Features/Python3F13 ), intended to be parallel-installable with the primary Python 2.6 stack, and this means that for various library packages I'll want to configure them to build python against both Python 2 and Python 3.

I'm about to attach a hacked-up version of python.m4 as python3.m4, which defines an AM_PATH_PYTHON3 macro.

I'm using this in my version of rpm's configure.ac in order to configure rpm to build two sets of python bindings, one for /usr/bin/python, the other for /usr/bin/python3  (see bug 531543)

(Note that I have to manually delete a couple of cache entries, to avoid AC_CACHE_CHECK from picking up the cached 2.6 Python.h when testing for the 3.1 Python.h, similarly for the libs)

Version-Release number of selected component (if applicable):
automake-1.11-2.fc11.noarch
Comment 1 Dave Malcolm 2009-11-09 14:16:32 EST
Created attachment 368273 [details]
Hacked up python3.m4, from python.m4, defining an AM_PATH_PYTHON3
Comment 2 Bug Zapper 2009-11-16 10:21:43 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Dave Malcolm 2010-01-14 18:53:20 EST
Does this look sane?

Note that python3 is now available in rawhide: http://lists.fedoraproject.org/pipermail/devel/2010-January/129185.html
Comment 4 Dave Malcolm 2010-02-11 15:00:12 EST
Have you had a chance to look at this?
Comment 5 Bug Zapper 2010-03-15 09:00:11 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Dave Malcolm 2010-05-17 15:54:25 EDT
I'm not sure if my patch is correct, but I'm increasingly trying to
support building Python extensions against multiple python runtimes
within a single rpm build - we have two python runtimes in Fedora 13:
python 2, python 3, and in Fedora 14 I want to double this by adding
debug builds of these that add lots of useful reference tracking, but
change ABI, giving four python configurations.  Each has a different
path for its include files and a different DSO to link against.

So is there a sane way to do this kind of thing within the autotools,
and from within an rpmbuild?
Comment 7 Bug Zapper 2011-06-02 13:29:43 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Dave Malcolm 2011-10-07 10:56:53 EDT
Ping?
Comment 9 Dave Malcolm 2012-05-17 11:55:57 EDT
Still appears to be a problem with /usr/share/aclocal-1.7/python.m4 in automake17-1.7.9-15.fc17.1.noarch
Comment 10 Pavel Raiskup 2012-10-04 02:26:01 EDT
Created attachment 621351 [details]
Example with double environments

Hello Dave, I see several possible solutions:

  1. in your case is the cleaning of cashed variables quite good solution ..
     because this situation appears like unusual case

  2. disable cashing of variables inside python.m4

  3. add your python3.m4 script (seem like strongly non-upstream-able due to
     code duplicities)

  4. fix python.m4 and its AM_PATH_PYTHON macro to allow client to build
     against multiple python environments (which looks like upstream-able
     solution if the fix does not break existing applications).

Do you think this feature would be suitable also for automake upstream?  It
seems like it could be usable outside of Fedora but I'm not a python-plugin
developer so I can not say .. How this is done on other systems now?

I'm attaching simple patched python.m4 with an example for the (4) case, what
do you think about it?  Usage would be something like that:

  AM_PATH_PYTHON([2.7],,,2)
  AM_PATH_PYTHON([3.0],,,3)

Thanks,
Pavel
Comment 11 Fedora End Of Life 2013-04-03 16:13:03 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 12 Richard Marko 2014-02-04 09:08:06 EST
Would be nice to have this one as more packages are adding python3 support.
Comment 13 Pavel Raiskup 2014-06-16 04:30:21 EDT
I would like to look at this once more;  could somebody point me to packages
dealing with this topic?  Some package installing both python3 & python2 stuff
and using automake's AM_PATH_PYTHON.
Comment 14 Jakub Filak 2014-06-16 04:44:23 EDT
Hi Pavel, abrt uses AM_PATH_PYTHON - https://github.com/abrt/abrt/blob/master/configure.ac (line 59).
Comment 15 Pavel Raiskup 2014-06-19 09:10:49 EDT
(In reply to Jakub Filak from comment #14)
> Hi Pavel, abrt uses AM_PATH_PYTHON -
> https://github.com/abrt/abrt/blob/master/configure.ac (line 59).

Thanks, Jakube!

I tried propose concept:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17811

The bad news about this patch is that we can not apply that downstream only,
and even if upstream will fix that, we will still need to wait for official
upstream release (packages distributed with this feature may be
re-autoreconfed only with capable automake).

Still not sure what I should advice to packagers in general.  I'll think about
some general downstream solution.
Comment 17 Jan Kurik 2015-07-15 11:20:48 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 18 Fedora End Of Life 2016-11-24 05:25:46 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.