#179 closed enhancement (fixed)

rewrite our Makefile in Python instead of GNUmake

Reported by: zooko Owned by: somebody
Priority: major Milestone: undecided
Component: packaging Version: 0.6.1
Keywords: setuptools Makefile build Cc:
Launchpad Bug:


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.

Change History (9)

comment:1 Changed at 2007-10-19T23:12:51Z by zooko

  • Version changed from 0.6.0 to 0.6.1

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.

comment:2 Changed at 2008-01-26T00:06:37Z by warner

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


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

comment:3 Changed at 2008-01-28T04:28:38Z by 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.)


comment:4 Changed at 2008-06-01T20:39:52Z by warner

  • Milestone changed from eventually to undecided

comment:5 Changed at 2008-06-02T16:55:29Z by zooko

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

	./setup.py install

	./setup.py test

	./setup.py build

	./setup.py sdist_deb feisty


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.

comment:6 Changed at 2008-08-06T22:14:43Z by 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...

comment:7 Changed at 2008-09-12T05:48:07Z by 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.

comment:9 Changed at 2009-01-23T23:49:16Z by zooko

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.