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

Gregory P. Smith greg at krypto.org
Sun Feb 3 22:20:31 CET 2013


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
> > x86_64 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.

-gps


>
> Regards
>
> Antoine.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130203/fc5dfce7/attachment-0001.html>


More information about the Python-Dev mailing list