The Cygnus configure script predates autoconf. All of its interesting features have been incorporated into autoconf. No new programs should be written to use the Cygnus configure script.
However, the Cygnus configure script is still used in a few places: at the top of the Cygnus tree and in a few target libraries in the Cygnus tree. Until those uses have been replaced with autoconf, some brief notes are appropriate here. This is not complete documentation, but it should be possible to use this as a guide while examining the scripts themselves.
Cygnus configure does not use any generated files; there is no program corresponding to `autoconf'. Instead, there is a single shell script named `configure' which may be found at the top of the Cygnus tree. This shell script was written by hand; it was not generated by autoconf, and it is incorrect, and indeed harmful, to run `autoconf' in the top level of a Cygnus tree.
Cygnus configure works in a particular directory by examining the file `configure.in' in that directory. That file is broken into four separate shell scripts.
The first is the contents of `configure.in' up to a line that starts with `# per-host:'. This is the common part.
The second is the rest of `configure.in' up to a line that starts with `# per-target:'. This is the per host part.
The third is the rest of `configure.in' up to a line that starts with `# post-target:'. This is the per target part.
The fourth is the remainder of `configure.in'. This is the post target part.
If any of these comment lines are missing, the corresponding shell script is empty.
Cygnus configure will first execute the common part. This must set the shell variable `srctrigger' to the name of a source file, to confirm that Cygnus configure is looking at the right directory. This may set the shell variables `package_makefile_frag' and `package_makefile_rules_frag'.
Cygnus configure will next set the `build' and `host' shell variables, and execute the per host part. This may set the shell variable `host_makefile_frag'.
Cygnus configure will next set the `target' variable, and execute the per target part. This may set the shell variable `target_makefile_frag'.
Any of these scripts may set the `subdirs' shell variable. This variable is a list of subdirectories where a `Makefile.in' file may be found. Cygnus configure will automatically look for a `Makefile.in' file in the current directory. The `subdirs' shell variable is not normally used, and I believe that the only directory which uses it at present is `newlib'.
For each `Makefile.in', Cygnus configure will automatically create a `Makefile' by adding definitions for `make' variables such as `host' and `target', and automatically editing the values of `make' variables such as `prefix' if they are present.
Also, if any of the `makefile_frag' shell variables are set, Cygnus configure will interpret them as file names relative to either the working directory or the source directory, and will read the contents of the file into the generated `Makefile'. The file contents will be read in after the first line in `Makefile.in' which starts with `####'.
These `Makefile' fragments are used to customize behaviour for a particular host or target. They serve to select particular files to compile, and to define particular preprocessor macros by providing values for `make' variables which are then used during compilation. Cygnus configure, unlike autoconf, normally does not do feature tests, and normally requires support to be added manually for each new host.
The `Makefile' fragment support is similar to the autoconf `AC_SUBST_FILE' macro.
After creating each `Makefile', the post target script will be run (i.e., it may be run several times). This script may further customize the `Makefile'. When it is run, the shell variable `Makefile' will hold the name of the `Makefile', including the appropriate directory component.
Like an autoconf generated `configure' script, Cygnus configure will create a file named `config.status' which, when run, will automatically recreate the configuration. The `config.status' file will simply execute the Cygnus configure script again with the appropriate arguments.
Any of the parts of `configure.in' may set the shell variables `files' and `links'. Cygnus configure will set up symlinks from the names in `links' to the files named in `files'. This is similar to the autoconf `AC_LINK_FILES' macro.
Finally, any of the parts of `configure.in' may set the shell variable `configdirs' to a set of subdirectories. If it is set, Cygnus configure will recursively run the configure process in each subdirectory. If the subdirectory uses Cygnus configure, it will contain a `configure.in' file but no `configure' file, in which case Cygnus configure will invoke itself recursively. If the subdirectory has a `configure' file, Cygnus configure assumes that it is an autoconf generated `configure' script, and simply invokes it directly.
The C++ library configure system, written by Per Bothner, deserves special mention. It uses Cygnus configure, but it does feature testing like that done by autoconf generated `configure' scripts. This approach is used in the libraries `libio', `libstdc++', and `libg++'.
Most of the `Makefile' information is written out by the shell script `libio/config.shared'. Each `configure.in' file sets certain shell variables, and then invokes `config.shared' to create two package `Makefile' fragments. These fragments are then incorporated into the resulting `Makefile' by the Cygnus configure script.
The file `_G_config.h' is created in the `libio' object directory by running the shell script `libio/gen-params'. This shell script uses feature tests to define macros and typedefs in `_G_config.h'.
Go to the first, previous, next, last section, table of contents.