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

[Ryan Gonzalez]

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


>
>
>>
>>
>>>
>>> CMake seems like a plausible alternative that would avoid the
>>> bootstrapping problem (as even building it from source only requires a
>>> working C++ compiler for the platform, either native or
>>> cross-compiled): http://www.cmake.org/
>>>
>>> KDE switched over to CMake from autotools ~9 years ago
>>> (http://lwn.net/Articles/188693/) and plenty of other projects have
>>> either followed suit or simply never used autotools in the first
>>> place: http://www.cmake.org/Wiki/CMake_Projects
>>>
>>>
>> That was what I was referring to before.
>>
>
> I casually discussed the idea back at PyCon 2008 about using CMake and was
> told "no" because of potential build tool dependencies for CMake itself. So
> you have to make sure that you can prove CMake is highly portable.
>

I'm guessing that's because CMake is written in C++, which is a large
dependency.

I *really* wish someone on this earth still had a C++-to-C99 compiler like
cfront was.


>
>
>>
>>
>>> It's far too late in the 3.5 dev cycle to contemplate a change like
>>> that, but if anyone was looking for a potentially interesting side
>>> project, seeing exactly what was involved in getting CPython to build
>>> with CMake instead of autotools could be a worthwhile investigation:
>>>
>>> https://stackoverflow.com/questions/7132862/tutorial-for-converting-autotools-to-cmake
>>>
>>>
>> Someone is maintaining a set of CMake build files for Python 2.7
>> somewhere.
>>
>
> That's fine, but obviously things have been tweaked since then and this
> could only go into 3.x.
>
>
I know. Just an example to show it's possible.

So, here's what I've gathered thus far:

- Needs to be written in ANSI C89 and *only* ANSI C89
- Needs to support autotools-style
try-to-build-this-and-do-something-if-it-fails
- Needs to be nicer than autotools, otherwise this entire thread is 100%
pointless.



> -Brett
>
>
>>
>>
>>> Regards,
>>> Nick.
>>>
>>> --
>>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>>
>>
>>
>>
>> --
>> Ryan
>> If I were in a 10-story building glass-sided building and forced to write
>> either Go or autotools scripts, I’d jump out a window.
>> http://kirbyfan64.github.io/
>>
>>  _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150311/26b7eafb/attachment-0001.html>