rewrite our Makefile in Python instead of GNUmake

[zooko]

I just committed bf3f629a683fd4cb (and the preceding related patches) which moves one kludgey little system-compatibility function from Makefile to misc/find_trial.py. This reminds me once again that we seem to make our build system more maintainable by rewriting parts of it from GNUmake into Python, and perhaps we ought to go all the way, eliminate Makefile entirely, remove the manual dependency on the GNU make tool, and write each of our build features into a logically separate setuptools plugin.

By the way, setuptools plugins like that can be in separate files and could even be separately packaged if we want, such as ​the setuptools_darcs_plugin that I recently wrote.

[zooko]

I think the Next Step for this one is to pick the next build feature which would look better in Python as a setuptools plugin than it currently looks as a GNUmake target, and replace that one.

[warner]

FYI, it looks like the 'Python Buildutils' project has similar goals:

​http://buildutils.lesscode.org/

However I don't see any actual overlap between the commands they offer and the tasks we perform in our makefile.

[zooko]

I found some other setuptools plugins that might be useful. I wish I'd known about bbfreeze a month ago, before we put so much effort into persuading py2exe. (Of course, bbfreeze might not have been less effort, but it sounds like it might have made some of our issues easier.)

​http://mail.python.org/pipermail/distutils-sig/2008-January/008724.html

[zooko]

My long-term goal is to make the Makefile​ entirely redundant so that it consists of only a list of targets like this:

install:
	./setup.py install

test:
	./setup.py test

build:
	./setup.py build

deb-feisty:
	./setup.py sdist_deb feisty

etc.

Currently our ​install.html instructs the user to invoke make check-deps, make, and then make test.

Soon we'll be able to change this doc by removing make check-deps entirely, and by instructing users to run python ./setup.py build and python ./setup.py test. At that point we can remove GNU make from the list of manual dependencies.

[zooko]

Brian likes to use a makefile as a way to find out which commands the maintainer of the build system chose to offer. (I guess by something like grep ^.*: Makefile.) You can run ./setup.py --help-commands to get a list of commands that ./setup.py knows how to run, but this is answering a different question -- it isn't telling what commands the maintainer of the build system chose to add, because one of the points of the setuptools plugin approach is that the maintainer of the build system for package X doesn't have to do anything to add commands, nor does he even know what commands are available. For example, if someone created a setuptools plugin that runs trial on your packages, and you've installed that plugin on your system, then package_X/setup.py --help-commands will list that command as one of the ones that it can do, even though the maintainer of package X has never heard of it.

Even if I ever get around to implementing this ticket, there may still be a place for a makefile that lists likely targets, per the example above, or else maybe a text README document, or maybe a special ./setup.py --help-tahoe-commands...

[warner]

I've just pushed a number of patches that move a lot of functionality from the Makefile into our setup.py, via a number of helper subcommands. This has removed all of the platform-dependent code and pretty much all of the gnarly shell-quoting goop from the Makefile.

[zooko]

Here is a related discussion on tahoe-dev: ​http://allmydata.org/pipermail/tahoe-dev/2008-September/000799.html

[zooko]

The fact that ​http://allmydata.org/source/tahoe/trunk/docs/install.html process now works without requiring GNU make and that this is tested by buildbot (#434 (automate testing of installation)) means that I'm satisfied with the status of this ticket.

There is still functionality in Makefile, including make quicktest, the Windows and Mac package building, and more, but let's close this ticket and hopefully in the future people will gradually write more and more in setuptools and less and less in {{{GNU make}}].