directory, will reconfigure the build directory (but not its
subdirectories). This is most often used to have a @code{Makefile} update
itself automatically if a new source directory is available.
-@c (see @ref{Top, ,Introduction , bash}.)
-@c That's a rather extraordinary xref. What's it meant to clarify
-@c ---shell scripts in general?? Disabled, since we don't seem to have
-@c the doc anyhow.
@item Recursion
If the source directory has subdirectories that should also be
invocation of @code{configure}.
@item -nfp
-@c singular "target" due to apparent direction of configure.
@emph{No floating point} unit available on the target; configure to
avoid dependencies on hardware floating point.
-@c Can we even say "configure to use software floating point support"?
@item -norecursion
Configure only this directory; ignore any subdirectories. This is used
by the executable shell script @file{config.status} to reconfigure the
current directory. (see @ref{config.status}).
-@c Why *does* that use no recursion? Speed? geometric combinations
-@c under some other script?
@ignore
@c This is complicated enough without "no longer supported" entries.
@code{prefix} variables set to this value. (See @ref{Install Details}.)
@item -recurring
-@c Wouldn't it make more sense to call this "-quiet"?
+@c Wouldn't it make more sense to call this "-quiet"? (FIXME).
This option is used internally by @code{configure} when recurring on
subdirectories. Its sole purpose is to suppress status output. You can
override this effect with the @code{-verbose} option.
@item -tmpdir=@var{tmpdir}
Use the directory @var{tmpdir} for @code{configure}'s temporary files.
-@c default?
+The default is the value of the environment variable TMPDIR, or
+@file{/tmp} if the environment variable is not set.
@item -verbose
@itemx -v
To make this easier, the value of the @code{configure} variable
@code{prefix} can be set on the command line to @code{configure}
using the option @code{-prefix=}.
-@c This is self-referential. What was intended?: (See @ref{prefix}).
@node datadir, Install Details, prefix, Install Locations
The first line configures the source for @var{host1} to place host
specific programs in subdirectories of @file{/usr/gnu/H-@var{host1}},
and host independent files in @file{/usr/gnu/H-independent}.
-@c Self-ref? (See @ref{datadir}.)
The second line builds and installs all programs for @var{host1},
including both host independent and host specific files.
independent files are installed @emph{on top of} the host
independent files installed for @var{host1}. This results in a single
copy of the host independent files, suitable for use by both hosts.
-@c Won't make notice the installed copies aren't out of date and leave
-@c 'em alone?
NOTE: support for @code{-subdirs} and multiple hosts is at least
temporarily suspended. FIXME-soon
@example
configure @var{host1} @var{host2} -prefix=/usr/gnu
-@c and make something-or-other, surely?
+make all install
@end example
@node Install Details, , datadir, Install Locations
@sc{un*x} way to build programs, but it has limitations. For instance,
using this approach, you can only build for one host at a time.
-@c "Makefile" treated as ordinary word through most of this; I've left it
-@c that way since that seems to agree w ordinary usage. This one was
-@c @code'd; if the intent is to emphasize that we're now talking of it
-@c as a file, I suggest
-@c "...builds @file{Makefile} files"
We refer to the directories where @code{configure} builds a
Makefile as the @emph{build directories} or sometimes as
@emph{objdir} because these are the directories in which @code{make}
@section The format of the @file{configure.in} file
@kindex configure.in
-@c "per-invocation" replaced "declaration" below as name of 1st section
-@c to conform to usage later in doc.
A @file{configure.in} file for Cygnus configure consists of a
@dfn{per-invocation} section, followed by a @dfn{per-host} section,
followed by a @dfn{per-target} section, optionally followed by a
@code{SUBDIRS} using the value of @code{configdirs}. This can be used
to determine which directories to configure and build depending on the
host and target configurations.
-@c Most other matching makefile/config vars use the same name. Why not this?
+@c Most other matching makefile/config vars use the same name. Why not
+@c this? (FIXME).
@end defvar
@defvar{target_dependent}
@end defvar
@defvar{host}
-@c 1st ref to "canonical triple". Need explanation, or assume readers know?
-Contains the name that the user entered for the host. Since many
-things that the user could enter would map to the same canonical triple,
-this variable is innappropriate to use for picking available
-configurations. For that, use @code{host_cpu}, @code{host_vendor},
-and/or @code{host_os}. This variable is useful, however, for error
-messages.
+Contains the name that the user entered for the host. Since many things
+that the user could enter would map to the same output from
+@code{config.sub}, this variable is innappropriate to use for picking
+available configurations. For that, use @code{host_cpu},
+@code{host_vendor}, and/or @code{host_os}. This variable is useful,
+however, for error messages.
@end defvar
@defvar{host_cpu}
@example
# This file is a collection of shell script fragments used to tailor
# a template configure script as appropriate for this directory.
-# For more information, check any existing configure script.
-@c What does "any existing configure script" mean? That if one's been
-@c generated here it'll show how the frags are used?
+# For more information, see configure.texi.
configdirs=
srctrigger=warshall.c
projects / binutils-gdb.git / commitdiff