For my sins I sometimes build programs from source that use standard autoconf-created configure scripts. The whole autoconf system has a number of problems, which you can read people rant about at length, but my problem is that I almost invariably build things using various different non-default arguments. Which leads to what I call the 'configure memory problem': when it comes time to rebuild the package for whatever reason, how do I remember which configure arguments I used and recreate them? Especially, how do I have this sitting around in a convenient form that requires as little hand work as possible?

(Yes, configure will write all of this information in various magic files. Which it puts in the source directory, and which get deleted if you do a forceful enough 'make clean', and so on.)

I've gone through a number of evolutionary steps on this problem; not worrying about it at all and then discovering that I'd forgotten the necessary magic arguments and had to recreate them, putting a little script file that runs configure with the right arguments in the source directory where it will get deleted when I clean up the source directory, and putting the little script file in the parent directory where I will lose track of it. None of them were ultimately satisfactory, so my current solution is a master script that I named doconfig.

My version has a bunch of complications, but at its heart doconfig can be written as the following simple script:

#!/bin/sh
CONFDIR=$HOME/lib/$arch/src-configs

dname=$(basename $(pwd))
if [ -x $CONFDIR/$dname ]; then
   exec $CONFDIR/$dname
else
   echo $0: cannot configure $dname
fi

(The complications exist to deal with all of the cases where the directory you need to run configure in is not a handily named top level directory. My version has an overly complicated file that maps some amount of trailing directory components to a script name, so that I can say that X11/fvwm-cvs/fvwm maps to the fvwm-cvs script.)

As you might expect, this turns out to be a handy way of capturing my knowledge of how to configure specific packages on my systems. Its simplicity means that it's easy and fast to take advantage of, and that I write scripts means that it's easy enough to augment them for various situations (such as handling both 32-bit and 64-bit builds, where they need different configure arguments).