[Python-ideas] CPython needs to revamp/replace it's build system && Cross-compiling Python sucks

Nick Coghlan ncoghlan at gmail.com
Fri Mar 13 13:15:22 CET 2015


On 12 March 2015 at 04:30, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> On Wed, Mar 11, 2015 at 10:07 AM, Brett Cannon <brett at python.org> wrote:
>>
>>
>>
>> On Tue, Mar 10, 2015 at 11:40 AM Ryan Gonzalez <rymg19 at gmail.com> wrote:
>>>
>>> On Tue, Mar 10, 2015 at 8:43 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>>
>>>> On 10 March 2015 at 21:20, Russell Keith-Magee <russell at keith-magee.com>
>>>> wrote:
>>>> >
>>>> > On Tue, Mar 10, 2015 at 10:43 AM, Ryan <rymg19 at gmail.com> wrote:
>>>> >>
>>>> >> Russell Keith-Magee <russell at keith-magee.com> wrote:
>>>> >> >Hi Ryan,
>>>> >> >
>>>> >> >First off I'm no fan of autoconf, but...
>>>> >> >
>>>> >>
>>>> >> Who is other than the one who designed it? :)
>>>> >
>>>> > Let me be clear - there's a difference between "not a fan" and
>>>> > "calling for
>>>> > it's head". Autoconf is crufty, annoying, and sometimes aggravating -
>>>> > but it
>>>> > *works*, and has had some pretty seriously battle testing - both in
>>>> > the
>>>> > abstract "autoconf as a product", and in the specific "autoconf as
>>>> > used in
>>>> > Python". This isn't something that can be said of most of the
>>>> > alternatives
>>>> > in the abstract case, or *any* of the alternatives in the Python case.
>>>>
>>>> Building architecture dependent software is a genuinely hard problem,
>>>> which is why it's full of "80%" solutions like autotools and the
>>>> setuptools/distutils pairing. Yes, they're quirky and annoying, but
>>>> they also basically do their job, so folks tend to develop a high
>>>> tolerance level for their quirks.
>>>>
>>>> In our particular case, we also have the fun problem of "How do you
>>>> build CPython locally when you don't have a working Python interpreter
>>>> yet?". A number of the more interesting alternative C/C++ build
>>>> systems (like Meson, Scons, Waf and the Google "gyp" project that
>>>> powers the node-gyp native extension build system for Node.js) require
>>>> an already working Python interpreter to get things started (when
>>>> starting from a completely blank slate, even our own build sequence
>>>> has to build a deliberately broken partial interpreter just to freeze
>>>> importlib._bootstrap before going on to build a properly configured
>>>> one that can actually import modules).
>>>
>>>
>>> What about something like Google's new GN? It's designed to replace Gyp
>>> in building Chromium and is written in C++.
>>>
>>> I'm pretty sure using a build system written in Lua to build Python is
>>> kind of weird.
>>
>>
>>>
>>>
>>> With all that in mind...what exactly would be requirements that Python
>>> would need in an autotools replacement?
>>
>>
>> Can't require anything more than an ANSI C compiler basically. People run
>> Python in places where they don't have much more than gcc.
>
>
> Not even C99? Darn it...

C99 would probably be OK these days. If there's a good enough
cross-compiling story, I'm also not sure we should entirely rule out
C++, as it's potentially OK if *developing* CPython requires a
mainstream platform with a C++ compiler.

But yeah, you can see why folks look at this problem and end up
thinking "well, you know, maybe autotools isn't *that* bad..."

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list