Building Release Tarballs

From Audacity Wiki
Revision as of 06:39, 29 February 2012 by Mchinen (talk | contribs) (and note about gperf for libid3tag)
Jump to: navigation, search
Release tarballs are the Bzip2-compressed TAR archives of the Audacity source code which we release via SourceForge for every Audacity release.

Who uses them

They are used by three groups of people:

  • People interested in looking at and analysing the Audacity source code
  • People creating packages for Linux distributions like RPMs, DEBs and so on.
  • End-users on Linux and Unix systems who can't use a pre-compiled package because one doesn't exist or is not suitable for their needs.

These different users have slightly different needs, and all of them differ from the needs of the development team, which largely determine the layout of the Audacity SVN repository. For a walk-through of actually creating a release tarball, skip to Step by Step at the bottom of the page. The stuff inbetween is mostly rationale and explanation.

What to include

The rationale for deciding what goes in release tarballs was worked out roughly as follows: For Full Source tarball:

  • Anything in Audacity SVN needed to build Audacity (as released in binary form) on a bare system is included.
  • This means all the dependencies except wxWidgets (which isn't in SVN).

For Minimal Source tarball:

  • Anything for which Audacity SVN is the upstream source and which is needed to build Audacity, goes in.
  • Anything which is patched in Audacity SVN such that the upstream version is not sufficient to build Audacity, goes in.
  • Anything else doesn't.

The differences between the two tarballs are standard packages which are either optional (most of them) or assumed to be obtained via the system's package manager from their upstream source.

In practise this means that most of lib-src (except things too new to be used in releases or too old to be supported) goes into the Full tarball, but only the few Audacity-supported bits go into the Minimal tarball.

Cleaning up

Any generated files, editor droppings and CVS droppings are removed from the source tree to minimise the size of the tarball, as these files are not needed at any time but left over from previous development work. All the .svn directories are removed because they are only needed to use version control, not to compile anything. A purge of symlinks and other library files known to be left behind by the build system is done, as they have caused problems in the past (although the build system should clean them up itself when make distclean is run).

To clear out all compiled files and executables, make clean and make distclean are run through the whole file tree to remove anything previous makes may have run. This also runs maintainer mode rules in Automake based projects in order to ensure that the shipped files have the correct timestamps on and configure files to stop Automake being run when the tarballs are built on end user's systems (when it often doesn't work).

Step by step

Luckily for you, the process of creating release tarballs is almost completely automated by the shell script. These instructions assume you are using a Unix-like system where files have <CR> line endings, and a bourne-compatible shell is available. If this is not the case, then you are likely to encounter problems.

  1. Prerequisites: The script requires the unix2dos utility in addition to standard stuff like tar and bzip2. make distclean can require various different old versions of automake for different packages. I know at least version 1.10 is required. Probably not a bad idea to install all old versions made available by your distro. you will also need gperf to generate frametype.c in libid3tag (this sometimes works without gperf for some reason, but sometimes fails, so install it to be safe) and autogen to build.
  2. Start from an up to date *clean* SVN checkout. Make sure that you don't have locally modified files, conflicts or other issues in the local copy before you begin. This includes making sure you don't have, for example, local patch files lying around. Even if they are not added to svn they will get wrapped up in the tarball when the script is run. There is a page with CVS tips here; with SVN the principles are similar but some tricks are no longer necessary.
  3. Change directory to the top level of the SVN checkout, if you aren't there already.
  4. Look in src/Audacity.h to see what version and suffix are currently set. These will determine the name of the source tarball, so if necessary change them to define the tarballs you are trying to create.
  5. Run ./scripts/ quiet (not ./scripts/maketarball, which also exists but is outdated), to generate a new directory containing all the files that will end up in the tarball. The directory will be created alongside the SVN checkout directory, and named audacity-src-x.y.z where x.y.z is the version number which is automatically extracted from the Audacity source code. The quiet argument keeps the amount of output produced under control, whilst still providing some progress indication. It can be replaced with verbose to see the full file-by-file output. When running for the first time it's not a bad idea to run with verbose, because in quiet mode stderr is directed to /dev/null for many commands. You may see a note that the Makefiles are not up to date, and the script will rerun configure. This is fine.
  6. If you observe any error messages, then stop and check what has happened. You can ignore any make errors that make ignores, i.e. ones about distclean and clean targets not existing.
  7. Change directory into the release structure (../audacity-src-x.y.z).
  8. Before configuring, make sure that no '.deps' directories exist with 'find . -name ".deps"'. If you have these, you probably need to to install more recent versions of automake, because make distclean is failing.
  9. Check that it can be configured and compiled successfully. This is the minimal source tarball, to test the full source you need to unpack it (into a different directory).
  10. If you have to make changes, then remember to copy them back to your SVN tree and commit them before deleting the tarball and release structure and starting again.
  11. If the tarball compiles successfully for you, then upload it so other people can test it before release.