Build improvements

I've been busy recently making loads of improvements for dealing with binary releases and compilation:

• 0compile is now much easier to use.

  First, there's the new autocompile feature, where it takes the URL of a program and downloads and builds it, along with any required libraries. This should make it easier to compile and run programs like ROX-Filer on systems where up-to-date binaries aren't available.

  Secondly, 0compile is easier to use when compiling local source code (e.g. a GIT checkout) - you don't have to do the build in a separate directory and it takes the version information from the feed in the checkout, instead of taking a copy.

  Finally, it's better at tracking new versions of dependencies; if a new version is available then it will prompt you to do a clean build (or revert to the older version).

• 0release is a huge time-saver for making releases. Given the path to the local feed in a GIT checkout it can manage the whole release process for you: creating the release candidate, running the unit-tests, diffing against the previous version, signing the release with your GPG key, uploading to your server, testing the upload and updating the Zero Install feed. All you have to do is confirm the new version number and enter your pass-phrase.

  It's always been useful for releasing Python code, but for C programs it previously only published source code. Now, it can build binaries (possibly using remote or virtual machines to build for multiple platforms) and publish them too, automatically, for any program that can be built using 0compile.

• 0test provides an easy way to run your program's unit-tests with any dependencies, but the clever bit is that you can test combinations of versions. For example, you can test a new release against the last five releases of ROX-Lib with one command.

I've also patched ROX-CLib to use 0compile to compile. This has a number of advantages:

• You get a nice(ish) GUI, instead of an xterm, complete with a report-bug button if it doesn't work.
• Selecting the right architecture is handled by Zero Install (if used), so multi-arch support works. That is, if you run a 32-bit application it will use a 32-bit version of ROX-Lib. A 64-bit app with use the 64-bit version.
• The ROX-CLib code is now shorter.

I'm not sure what to do with this, though, because it does introduce a dependency on Zero Install (at compile-time, not run-time), which some people have been opposed to in the past. In many ways, this is good: making Zero Install optional forces us to make the architecture modular. On the other hand, code duplication is bad (the non-multi-arch-aware build code in ROX-CLib is also duplicated in Pager, Clock, and almost every other application using ROX-CLib). Likewise, the release scripts for programs not managed with 0release are duplicated all over the place.

I'd be particularly interested in feedback on these issues:

• Who else is using 0release? Does it work well for you? If not, what needs fixing?
• Can we agree that code duplication is bad, and that we should find a way to separate build and release code from individual programs? If depending on Zero Install isn't acceptable, what can we do instead to accommodate multiple build systems?