== How I solve the _configure_ memory problem 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).