[Python-ideas] Rewriting the build system (part 2)

[Chris Angelico]

On Tue, Mar 17, 2015 at 3:27 AM, Chris Barker <chris.barker at noaa.gov> wrote:
>>  someone
>> who has little knowledge of Python's internals, and just wants to
>> build the latest version (either from hg or from a source tarball).
>
>
> That's the assumption I'm following -- the user wants the latest version --
> so probably already has easy access to an older version with which to run
> the build tools...

The tricky part here is defining the oldest supported version. "To
build Python X.Y, you must already have Python ??? or later installed"
- how do you pick the minimum? The older that minimum, the more warped
the build code has to be (especially if you want to support 2.x as
well as 3.x - imagine trying to make it possible to use the system
Python on RHEL, as well as any 3.[1-4]), but go too far the other way
and you end up with a multi-step build process ("first build Python
3.4, then use that to build Python 3.7") which is just going to be a
pain.

>> But in the second case, it'd be much safer to minimize the
>> requirements. If you can untar the source and just "./configure; make;
>> sudo make install" your way to having the latest Python, that's a LOT
>> easier than I've just been doing trying to get my Dad onto a newer
>> Mozilla Thunderbird. (I don't understand what it's doing all along
>> there, but it pulls a whole bunch of separate repositories when I say
>> update, and there's a separate bootstrap step, and ... I dunno.)
>
>
> requiring _some_, not very recent, python is not exactly
>
>  """a whole bunch of separate repositories when I say update, and there's a
> separate bootstrap step"""
>
> If there is an already build python (like OS-X, any general purpose linux
> distro, Windows if you don't mind point and clicking the python.org
> installer, etc, then it's not really a "bootstrap".

No, that's not what I'm talking about. I'm talking about trying to
build Thunderbird and having to do a bunch of steps where I run this
program, then run that, then let it chug its way through stuff, and
then eventually it'll start building. Without detailed knowledge of
the build internals I have no way of knowing what steps I can skip, so
every time I want to test the build again, I have to go through them
all. It took three parts of forever to figure out what was going on.

I much prefer projects that ship with the standard "./configure; make"
pattern. I don't care if the configure script is built by some arcane
incantation, as long as it's checked into source control (or at very
least is in the downloadable source tarball for any particular
version). If I want to build your program, I don't want to have to
hunt down your notes file, read it through in detail, and jump through
a dozen hoops; I just want to point my compiler at your source, and
then go make myself a hot chocolate while it does its work.

ChrisA