Bug 807780

Summary:	[RFE] Build with Python3 support
Product:	[Fedora] Fedora	Reporter:	Ben Boeckel <fedora>
Component:	boost	Assignee:	Petr Machata <pmachata>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	denis.arnaud_fedora, julian.fedora, mnewsome, pertusus, pmachata, pnemade
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-08 15:52:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ben Boeckel 2012-03-28 17:11:06 UTC

Description of problem:
boost-python should also be built with Python3 support. With bjam, adding a "using python : 3.2 ;" line is enough to get an additional boost_python3 library built. Not sure what would need to change in the CMake code.

Comment 1 Petr Machata 2012-05-02 15:29:20 UTC

We will have to make another serial build for Python module.  Passing the following to cmake seems to cause it detecting the right Python version:
  -DPython_ADDITIONAL_VERSIONS=3.2mu -DPYTHON_EXECUTABLE=python3

The first flag is not enough unfortunately, because the logic in FindPythonInterp.cmake prefers default unversioned python over anything else, so we have to force it with the second flag.

The "mu" suffix in version is to reflect the Python ABI that we use in Fedora.  Ideally, FindPythonLibraries.cmake would be able to figure it by itself, but alas it's not.  This happens to work, because the ABI suffix happens to be after Python version in library name as well as include path.

Comment 2 Petr Machata 2012-05-02 15:35:38 UTC

Ah, and of course the parallel builds will need to be re-made for Python 3 as well.

I'm also not sure how to ship the Python 3 libraries.  If we call them differently (so as to make them parallel installable with Python 2.7 versions), the build systems won't find them.  If we call them the same, they won't be parallel installable.

Comment 3 Ben Boeckel 2012-05-02 15:53:56 UTC

I had a patch to the CMake list to fix FindPython* support for Python3 properly (the ABIFLAGS need to be searched for manually; setting additional versions here really only works because we're downstream). Creating the library as boost_python3 is what I'm doing currently for my Boost builds locally (bjam can build against multiple Python versions at once). I don't see any issue with it being a different name since I'm seeing a 5x slowdown when running against Python3 rather than Python2 anyways.

Comment 4 Petr Machata 2012-05-02 16:24:22 UTC

Ok, I'll call them libboost_python3 etc.

Comment 5 Petr Machata 2012-05-02 21:49:50 UTC

I'm spinning a new build of boost which should include a boost-python3 package with libraries for integration with Python 3.  Would you please be so kind as to test whether that solves your problem?  The build is http://koji.fedoraproject.org/koji/taskinfo?taskID=4047186

Note that I left boost-{openmpi,mpich2}-python alone for the time being.  As far as I understand it, those are currently broken anyway (see RHEL bug 801534 for details).

Comment 6 Parag Nemade 2012-08-05 13:38:35 UTC

Include python3 support in boost-1.50 build. Many packages are failing now in rawhide.

Comment 7 Petr Machata 2012-08-08 15:52:12 UTC

This should be taken care of now.  f18 is built, rawhide is spinning.