Incredibly, somehow everyone else missed the canonical way to do this, which has been around since 2 years before this thread began. :-)

I wondered the same thing as the OP and was disappointed by the lack of proper (non-ugly) ways to do this when I read this thread.

A few days later, while idly browsing release notes for Autoconf, I reached the release notes for Autoconf 2.65. And would you believe it?

Major changes in Autoconf 2.65 (2009-11-21) [stable]

[...]

config.status now provides a --config option to produce the configuration.

So, just running ./config.status --config does precisely what the OP asked for.

Here is the corresponding reference in the documentation: 17 config.status invocation, and a quote:

--config

Print the configuration settings in reusable way, quoted for the shell, and exit. For example, for a debugging build that otherwise reuses the configuration from a different build directory build-dir of a package in src-dir, you could use the following:

args=`build-dir/config.status --config`
eval src-dir/configure "$args" CFLAGS=-g --srcdir=src-dir

./configure --help

That will show you all options for that particular configure script.

The --build and -host options are to configure scripts are standard configure options, and you very rarely need to specify them unless you are doing a cross-build (that is, building a package on one system to run on a different system). The values of these options are called "triples" because they have the form cpu-vendor-os. (Sometimes, as in your case, os is actually kernel-os but it's still called a triple.)

The base configure script is quite capable of deducing the host triple, and you should let it do that unless you have some really good evidence that the results are incorrect. The script which does that is called config.guess, and you'll find it somewhere in the build bundle (it might be in a build-aux subdirectory). If you're doing a cross-build and you need to know the host triple, the first thing to try is to run config-guess on the host system.

The values supplied (or guessed) for --host and --build are passed through another script called config.sub, which will normalize the values. (According to the autoconf docs, if config.sub is not present, you can assume that the build doesn't care about the host triple.) The developers of a specific software package might customize the config.sub script for the particular needs of their build, and there are a lot of different versions of the standard config.sub script, so you shouldn't expect config.sub from one software package to work on another software package, or even on a different version of the same software package.

Despite all the above, autoconf'ed software packages really should not need to know the names of the host os and vendor, except for identifying default filesystem layout so that they provide the correct default file locations.

You can read through config.sub to get an idea of the range of options which will be recognized, but it is not so easy to figure out how the values are used, or even if the values are used. The first field -- the cpu -- is the most likely to be used.

You can get a list of all the options by typing:

./configure --help

or, better,

./configure --help | less

since there are always a lot of options.

Other than the standard options (--build, --host and --target as above, and the options which override file locations), the specific options allowed by each configure script are different. Since they also tend to change from version to version of the software package, you should always check the configure script itself rather than relying on external documentation.

Unfortunately, the contents of the configure script's help are not always 100% complete, because they rely on the package developers to maintain them. Sometimes unusual or developer-only options are not part of the ./configure --help output, but that is usually an indication that the option should not be used in a normal install.

To expand $HOME in your file you could use envsubst first (be aware this will expand any env variable). Then you could read the result into an array e.g. with zsh

args=(${(f)"$(< <(envsubst <infile))"})

or with bash

readarray -t args < <(envsubst <infile)

and then run

./configure "${args[@]}"

Alternatively, you could use tr to format the result as a single line of options preceded by ./configure, and pipe that to sh:

{ printf %s './configure '; tr '\n' ' ' <infile; } | sh

Because each step does different things

Prepare(setup) environment for building

./configure

This script has lots of options that you should change. Like --prefix or --with-dir=/foo. That means every system has a different configuration. Also ./configure checks for missing libraries that should be installed. Anything wrong here causes not to build your application. That's why distros have packages that are installed on different places, because every distro thinks it's better to install certain libraries and files to certain directories. It is said to run ./configure, but in fact you should change it always.

For example have a look at the Arch Linux packages site. Here you'll see that any package uses a different configure parameter (assume they are using autotools for the build system).

Building the system

make

This is actually make all by default. And every make has different actions to do. Some do building, some do tests after building, some do checkout from external SCM repositories. Usually you don't have to give any parameters, but again some packages execute them differently.

Install to the system

make install

This installs the package in the place specified with configure. If you want you can specify ./configure to point to your home directory. However, lots of configure options are pointing to /usr or /usr/local. That means then you have to use actually sudo make install because only root can copy files to /usr and /usr/local.

Now you see that each step is a pre-requirement for next step. Each step is a preparation to make things work in a problemless flow. Distros use this metaphor to build packages (like RPM, deb, etc.).

Here you'll see that each step is actually a different state. That's why package managers have different wrappers. Below is an example of a wrapper that lets you build the whole package in one step. But remember that each application has a different wrapper (actually these wrappers have a name like spec, PKGBUILD, etc.):

def setup:
... #use ./configure if autotools is used

def build:
... #use make if autotools is used

def install:
... #use make all if autotools is used

Here one can use autotools, that means ./configure, make and make install. But another one can use SCons, Python related setup or something different.

As you see splitting each state makes things much easier for maintaining and deployment, especially for package maintainers and distros.