6.5 Using Configuration Names

back: what to check for
forward: introducing gnu automake
 
fastback: writing configure.in
up: writing configure.in
fastforward: introducing gnu automake
top: autoconf, automake, and libtool
contents: table of contents
index: index
about: about this document

While feature tests are definitely the best approach, a `configure' script may occasionally have to make a decision based on a configuration name . This may be necessary if certain code must be compiled differently based on something which can not be tested using a standard Autoconf feature test. For instance, the expect package needs to find information about the system's `tty' implementation; this can't reliably be done when cross compiling without examining the particular configuration name.

It is normally better to test for particular features, rather than to test for a particular system type. This is because as Unix and other operating systems evolve , different systems copy features from one another.

When there is no alternative to testing the configuration name in a `configure' script, it is best to define a macro which describes the feature, rather than defining a macro which describes the particular system. This permits the same macro to be used on other systems which adopt the same feature (see section 23. Writing New Macros for Autoconf).

Testing for a particular system is normally done using a case statement in the autoconf `configure.in' file. The case statement might look something like the following, assuming that `host' is a shell variable holding a canonical configuration system--which will be the case if `configure.in' uses the `AC_CANONICAL_HOST' or `AC_CANONICAL_SYSTEM' macros.

 
 case "${host}" in i[[3456]]86-*-linux-gnu*) do something ;; sparc*-sun-solaris2.[[56789]]*) do something ;; sparc*-sun-solaris*) do something ;; mips*-*-elf*) do something ;; esac 

Note the doubled square brackets in this piece of code. These are used to work around an ugly implementation detail of autoconf ---it uses M4 under the hood. Without these extra brackets, the square brackets in the case statement would be swallowed by M4, and would not appear in the resulting `configure' . This nasty detail is discussed at more length in 21. M4.

It is particularly important to use `*' after the operating system field, in order to match the version number which will be generated by `config.guess' . In most cases you must be careful to match a range of processor types. For most processor families, a trailing `*' suffices, as in `mips*' above. For the i386 family, something along the lines of `i[34567]86' suffices at present. For the m68k family, you will need something like `m68*' . Of course, if you do not need to match on the processor, it is simpler to just replace the entire field by a `*' , as in `*-*-irix*' .


This document was generated by Gary V. Vaughan on May, 24 2001 using texi2html


GNU Autoconf, Automake and Libtool
GNU Autoconf, Automake, and Libtool
ISBN: 1578701902
EAN: 2147483647
Year: 2002
Pages: 290

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net