File: autoconf.info,  Node: Using System Type,  Prev: Canonicalizing,  Up: Manual Configuration

14.3 Using the System Type
==========================

In ‘configure.ac’ the system type is generally used by one or more
‘case’ statements to select system-specifics.  Shell wildcards can be
used to match a group of system types.

   For example, an extra assembler code object file could be chosen,
giving access to a CPU cycle counter register.  ‘$(CYCLE_OBJ)’ in the
following would be used in a makefile to add the object to a program or
library.

     AS_CASE([$host],
       [alpha*-*-*], [CYCLE_OBJ=rpcc.o],
       [i?86-*-*],   [CYCLE_OBJ=rdtsc.o],
       [CYCLE_OBJ=""])
     AC_SUBST([CYCLE_OBJ])

   ‘AC_CONFIG_LINKS’ (*note Configuration Links::) is another good way
to select variant source files, for example optimized code for some
CPUs.  The configured CPU type doesn't always indicate exact CPU types,
so some runtime capability checks may be necessary too.

     AS_CASE([$host],
       [alpha*-*-*],   [AC_CONFIG_LINKS([dither.c:alpha/dither.c])],
       [powerpc*-*-*], [AC_CONFIG_LINKS([dither.c:powerpc/dither.c])],
       [AC_CONFIG_LINKS([dither.c:generic/dither.c])])

   The host system type can also be used to find cross-compilation tools
with ‘AC_CHECK_TOOL’ (*note Generic Programs::).

   The above examples all show ‘$host’, since this is where the code is
going to run.  Only rarely is it necessary to test ‘$build’ (which is
where the build is being done).

   Whenever you're tempted to use ‘$host’ it's worth considering whether
some sort of probe would be better.  New system types come along
periodically or previously missing features are added.  Well-written
probes can adapt themselves to such things, but hard-coded lists of
names can't.  Here are some guidelines,

   • Availability of libraries and library functions should always be
     checked by probing.
   • Variant behavior of system calls is best identified with runtime
     tests if possible, but bug workarounds or obscure difficulties
     might have to be driven from ‘$host’.
   • Assembler code is inevitably highly CPU-specific and is best
     selected according to ‘$host_cpu’.
   • Assembler variations like underscore prefix on globals or ELF
     versus COFF type directives are however best determined by probing,
     perhaps even examining the compiler output.

   ‘$target’ is for use by a package creating a compiler or similar.
For ordinary packages it's meaningless and should not be used.  It
indicates what the created compiler should generate code for, if it can
cross-compile.  ‘$target’ generally selects various hard-coded CPU and
system conventions, since usually the compiler or tools under
construction themselves determine how the target works.