Here's a typical scenario - you install software from source, spend an hour figuring out the configure options, and finally run:

./configure --prefix=/a/b/c --with-X --with-Y \
  --with-Z-dir=/usr/local/Z --enable-A --disable-B

A year passes by, a new software version has come out, and you want to upgrade. To do that you need to run configure again on the new source code. However you've forgotten what the configure flags were because it's been a year.

If you're lucky, you still have the old build somewhere in your home directory. Here's what you do. You go into the old build directory and run this:

./config.status --config

This will output the exact configure arguments that you used to configure the software. You just saved yourself an hour of work trying to remember all the arguments.


October 15, 2014, 07:15

I set HISTSIZE and HISTFILESIZE to 200000 (two hundred thousand) and then use Ctrl-r to reverse search. You have to remember part of the command this way, but until now this works for me.


October 15, 2014, 13:17

That's a good one. I did the same before I learned about config.status. You can ctrl-r and then type ./configure to find the options.

Fernando Basso Permalink
March 06, 2015, 22:41

I'm not sure if after a year my command line history would still remember the configure command even if it were set to 200000 lines long. But I'm just guessing. :)

Chris B. Permalink
October 15, 2014, 15:41

Years ago I got into the habit of using the script command to capture the configure command and its output and then subsequent make command(s) as well.

Antony Dovgal Permalink
October 15, 2014, 17:52

Just use a config.nice script.
Google it, it's easy to add a macro that would create config.nice on each configure run.

zoredache Permalink
October 16, 2014, 18:34

Better yet, don't manually configure things by hand, put it in a script (either your own or as part of a packaging tool), put your script in a VCS.

Even better do all the work with a configuration management tool.

anon Permalink
December 21, 2014, 03:33

I'm not sure what's worse - not documenting the process of building software from source of having one year old trash directories where one builds software manually like that.

Leave a new comment

(why do I need your e-mail?)

(Your twitter name, if you have one. (I'm @pkrumins, btw.))

Type the word "browser_437": (just to make sure you're a human)

Please preview the comment before submitting to make sure it's OK.