View source for Note on configure files

Many packages are simple enough that building and installing them on Linux only requires the "./configure; make; make install" steps. But some require tailoring options for your environment; after all, if they did not, you could probably just use the RPM package in the first place (if available) and skip the whole build process.

Once I know how I want to configure a package I typically create a script to speed up installing upgrades or moving it to new systems. The script usually consists of one command split across many lines, for example if I am building a package named '''foo''', the file will contain something like this.

 ./configure \
  prefix=/usr/local/foo \    ''where to install''
  with-some-library \        ''use an external library called 'some-library' ''
  enable-wonderful-feature   ''turn on 'wonderful feature' ''

I store this in a file called CONFIGURE.foo, at the same level as the package tar file and the unpacked source tree. So building consists of these steps:

  tar xzf foo-''some-version-number''.tar.gz
  cd foo-''some-version-number''
  sh ../CONFIGURE.foo
  make
  su
  make install

On a few rare occasions there are extra lines ahead of the ./configure line that do things such as set up environment variables or modify the PATH.

Of course, the very first time I download the package, I don't have any such script. There is a lengthy process of reading the INSTALL doc, running ./configure --help, and devising a list of the options that I need.
But once I have done that, I have a relatively stable set of options stored in a file near the source tree. When I download newer versions I usually can get by with a quick check of the docs followed by the above steps.

Another method I have seen used is to wrap the whole process up in a script, something like this:

  #!/bin/sh
  cd ''directory''
  ./configure ''configure options''
  make
  su
  make install

I prefer my simpler method because I would have to edit the '''directory''' line each time I downloaded a new release. (Changing php-4.4.0 to php-4.4.1 for example.) Also I like to check output from the configure step before doing the make. Sometimes I catch things at that stage that I would miss if I used this script.