I’ve written a Makefile to help build and distribute Personas and Snowl. It automates the process of generating manifests; packaging the extension into a JAR and a XPI; and, for a “development” distribution channel, autogenerating successive version numbers and rsyncing the builds and update.rdf file to a distribution server.

The file makes it easy for me to update the latest development build of Personas after checking in a fix via:

make build channel=dev make package channel=dev make publish

For release builds, it’s:

make build channel=rel make package channel=rel [manually upload to AMO]

And when I just want to test locally, I can build and install to a local profile:

make build make install profile=~/dev-profile firefox -profile ~/dev-profile

Or I can package the build and install via Firefox’s Add-ons Manager:

make build make package [manually install via Firefox's Add-ons Manager]

Because I reuse it for multiple projects, project-specific variables are defined in a separate client.mk file. If you have similar needs and would find it useful, you are welcome to it!

Just grab the Makefile, see client.mk for the variables you should define, and check out the Personas source directory for the general layout that the Makefile handles as well as the install.rdf.in, chrome.manifest.in, and update.rdf.in templates from which their respective files are built.

Notes:

1. It’s originally based on Weave’s top-level Makefile, although it doesn’t currently support the binary components that Weave’s Makefile builds.
2. It assumes a directory structure in which content/, locale/, and skin/ directories are at the top level of the source directory (not within a chrome/ subdirectory).
3. It currently builds in the source directory rather than in an object directory, which means it can leave old install.rdf, chrome.manifest, and chrome.jar files around, so sometimes I need to make clean && make build to get rid of the ones I previously built (f.e. for a release build whose chrome files are archived) and generate new ones for continued development.
4. For Personas, I use a defaults/preferences/prefs.js.in template to generate prefs that contain the Mercurial revision ID (so I can identify the version of code in a development build with which someone is reporting problems) and the distribution channel (which the extension uses to suppress the “You’ve been updated!” page for the “dev” channel, since that would get annoying fast).