[Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build (original) (raw)

Matthias Klose doko at ubuntu.com
Mon Feb 4 21:04:39 CET 2013

Am 03.02.2013 22:20, schrieb Gregory P. Smith:

On Thu, Jan 31, 2013 at 11:14 PM, Antoine Pitrou <solipsis at pitrou.net>wrote:

On Fri, 1 Feb 2013 11:00:24 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote: On Fri, Feb 1, 2013 at 9:50 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Thu, 31 Jan 2013 23:52:27 +0100 (CET) matthias.klose <python-checkins at python.org> wrote:

http://hg.python.org/cpython/rev/8ee6d96a1019 changeset: 81859:8ee6d96a1019 branch: 2.7 parent: 81855:df9f8feb7444 user: doko at python.org date: Thu Jan 31 23:52:03 2013 +0100 summary: - Issue #17086: Backport the patches from the 3.3 branch to cross-build the package.

You aren't supposed to add new features to bugfix branches. Did you have a specific reason to do this? One of the reasons for the long maintenance period on 2.7 is to keep it building as the underlying platforms change. With the rise of ARM systems, being able to reliably cross-build Python 2.7 for ARM from an x8664 system is fairly important. I would like to see a better argument for this. The rise of ARM systems is the rise of ARM systems powerful enough to build Python without cross-compiling (which is why we now have ARM buildbots). The very small ARM systems which need cross-compiling have existed for decades. It is quite common for developers to build a single code base on a single workstation targeting a plethora of platforms all at once. Requiring native systems with self hosting tool-chains for builds is a non-starter as those often don't exist. Making Python 2.7's configure+makefiles easier to cross compile out of the box is a good thing. Side note: we really need a cross compiling build-bot host + target system or we'll inevitably break this. That said, as a procedural point for build related new features in 2.7, I agree they should be proposed, with an explicit rationale, on python-dev before proceeding with the commit. I think this huge changeset should be reverted. It's a complete failure in terms of procedure and following the rules. "Just because it can be useful" is not a good enough reason to violate our release model without even asking. That's up to the 2.7 release manager. Yes, this could have been done better by asking first. But IMNSHO I'd prefer to see it stay in.

I filed Issue #17086, and got feedback from the release manager, which I maybe interpreted too easily as not objecting. And it looked like a nice opportunity to get this into a release (hoping not to listen to another PyCon talk how to hack cross-builds).

Even for the trunk, getting feed-back for cross-build related issues is difficult. Maybe reviewers are turned off by impolite comments in some of the cross-build related issues in the bug tracker, but that doesn't explain that you don't get feedback for most of the cross-build issues.

So what I do understand, build-related issues like an arm64 or mingw32 port are ok for 2.7, if they are stable on the trunk, and communicated on python-dev?

I'll see that I setup a cross buildd building in a cross-build environment and testing in a chroot with qemu installed. I hope that the buildd setup is able to support this.

Talking about the release model, yes I think there are some issues:

Matthias

PS: Antoine: Please CC the committer for such emails.

More information about the Python-Dev mailing list