Automake Software Release Cycle

For a short while, I was responsible for the software releases of zcip, but since I did not actively use the software, I lost interest.

Nevertheless, I found that releasing software is prone to errors, and made the following list to make sure I did not forget anything.

Macro, Gcc, Make, Autoconf and Automake
This release cycle is a geared towards software that used configure and make scripts, which are often used in the C and C++ programming language. In case you are not familiar with these tools and script. Here is the short description.

C and C++ are ugly hackery languages that are so hackery that it is highly non-trivial to run them on different architectures, and even are not able to handle incompatibilities in the code itself. For that reason, the code contains macros. To determine which macro is used, the gcc compiler is fed options on the command line. E.g. gcc -I. -I dir code.c.

In order so that users don't have to remember all these silly options, a Make script is created.

However, the Make script may become so complex in order to determine the architecture, that it is necessary to create a configure script which create the Make based on the user preferences and the software architecture at hand.

The configure script is the one that is distributed to users who compile the software on their architectures.

However, the configure script may become so complex that is was necessary to create yet another script to create the configure script (are you still there?). In fact, due some complexity, there are in fact three or four scripts that create these scripts (configure.ac is the base, and automake, autoconf and autoheader turn this in the appropriate scripts).

So we now have a (automake/autoconf) script that creates a configure script, that creates a Make script that adjusts the source code that creates a program.

In case you still think this is the way to make and deliver software to users, read on.

Edit files

 * autoreconf (you can also call autogen.sh)
 * configure.ac (historically sometimes named configure.in)
 * Makefile.am

run autoreconf
(autoreconf is the same as the autogen.sh script)
 * libtoolize: install ltmain.sh (only if libtool is used)
 * aclocal: configure.ac → aclocal.m4 (deprecated, see 5.7-5.9 of automake manual)
 * automake: Makefile.am & configure.ac → Makefile.in
 * autoconf: configure.ac & aclocal.m4 & acinclude.m4 → configure
 * autoheader: configure.ac → config.h.in

The following command is only run by individual users:
 * configure: Makefile.in → Makefile; config.h.in → config.h

Adjuct Documentation

 * version nummer in the header files (for ./mytool --version)
 * Changelog: run "cvs2cl", remove ChangeLog.bak if Changelog is OK.
 * Is README up-to-date? (references to mailinglist, etc)
 * Is TODO up-to-date?
 * Have downstream patches been incorporated?

Create New Configure Script
run autoreconf (alternatively, run autogen.sh, which does the same)

Create tag
Note: do not create a new branch, unless you want to maintain two versions of your software in the future.

First commit all changes

Release the Package

 * Create the package with "make distcheck" (this is the same as "make dist" but adds some sanity checks)
 * upload result to ftp://uploads.sourceforge.net/incoming/ with anonymous FTP
 * Add in Admin → File Releases
 * Download package and check the SHA-2 checksum.
 * Send an e-mail to the mailing list and downstream maintainers.