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

[Ryan Gonzalez]

On Mon, Mar 16, 2015 at 11:50 AM, Chris Angelico <rosuav at gmail.com> wrote:

> 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.
>
>
Sounds like Go is now. It's 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.
>
>
All of Mozilla's build systems need help. They have a build system genius
who wrote Tup working for them, and they somehow still have 20,000 stupid
mozbuild files with some weird, intensely slow make-based system that
everyone complains about.


> 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.
>
>
Most of that is bad documentation. If there's no configure script but a
file labeled INSTALLING, then that should contain simple instructions to
build.

I hate most tools that ship with configure scripts because 70% of the time
some stupid test does some stupid thing wrong and gives the worst errors,
29% of the time the configure system doesn't pick up my options correctly,
and 1% of the time it actually *works*.

SCons also constantly gives me trouble.

Of course, you could always do it the plan9port way:

ryan at DevPC-LX:~/stuff/plan9port$ ./configure
read the README file.
ryan at DevPC-LX:~/stuff/plan9port$


> ChrisA
> _______________________________________________
> 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/20150316/c6463fbd/attachment.html>