@code{m4_include} is seldom used by @file{configure.ac} authors, but
can appear in @file{aclocal.m4} when @command{aclocal} detects that
-some required macros come from files local to your package (as
-opposed to macros installed in a system-wide directory, see
-@ref{Invoking aclocal}).
+some required macros come from files local to your package (as opposed
+to macros installed in a system-wide directory, @pxref{Invoking
+aclocal}).
@end ftable
and uses @code{m4_include} instead of copying it into
@file{aclocal.m4}. This makes the package smaller, eases dependency
tracking, and cause the file to be distributed automatically.
-(See @ref{Local Macros} for an example.) Any macro which is found in a
+(@xref{Local Macros}, for an example.) Any macro which is found in a
system-wide directory, or via an absolute search path will be copied.
So use @code{-I `pwd`/reldir} instead of @code{-I reldir} whenever
some relative directory need to be considered outside the package.
@cindex suffix @file{.la}, defined
@cindex @file{.la} suffix, defined
-Libtool abstracts shared and static libraries into a unified
-concept henceforth called @dfn{libtool libraries}. Libtool libraries
-are files using the @file{.la} suffix, and can designate a static
-library, a shared library, or maybe both. Their exact nature cannot
-be determined until @file{./configure} is run: not all platforms
-support all kinds of libraries, and users can explicitly select which
+Libtool abstracts shared and static libraries into a unified concept
+henceforth called @dfn{libtool libraries}. Libtool libraries are
+files using the @file{.la} suffix, and can designate a static library,
+a shared library, or maybe both. Their exact nature cannot be
+determined until @file{./configure} is run: not all platforms support
+all kinds of libraries, and users can explicitly select which
libraries should be built. (However the package's maintainers can
-tune the default, @ref{AC_PROG_LIBTOOL, , The @code{AC_PROG_LIBTOOL}
+tune the default, @pxref{AC_PROG_LIBTOOL, , The @code{AC_PROG_LIBTOOL}
macro, libtool, The Libtool Manual}.)
@cindex suffix @file{.lo}, defined
@code{EXTRA_*_SOURCES} variables are used to keep track of source
files that might be compiled (this is mostly useful when doing
-conditional compilation using @code{AC_SUBST}, see @ref{Conditional
+conditional compilation using @code{AC_SUBST}, @pxref{Conditional
Libtool Sources}), and the @code{nodist_} prefix means the listed
sources are not to be distributed (@pxref{Program and Library
Variables}). In effect the file @file{dummy.cxx} does not need to
languages, support for which will be improved based on user demand.
Some limited support for adding your own languages is available via the
-suffix rule handling; see @ref{Suffixes}.
+suffix rule handling (@pxref{Suffixes}).
@node ANSI
@samp{nodist_} prefix as in @code{nodist_include_HEADERS} or
@code{nodist_prog_SOURCES}. If these generated headers are needed
during the build, you must also ensure they exist before they are
-used, see @ref{Sources}.
+used (@pxref{Sources}).
@node Data
@item @code{no-dependencies}
@cindex Option, @code{no-dependencies}
@opindex no-dependencies
-This is similar to using @samp{--include-deps} on the command line, but
-is useful for those situations where you don't have the necessary bits
-to make automatic dependency tracking work @ref{Dependencies}. In this
-case the effect is to effectively disable automatic dependency tracking.
+This is similar to using @samp{--include-deps} on the command line,
+but is useful for those situations where you don't have the necessary
+bits to make automatic dependency tracking work
+(@pxref{Dependencies}). In this case the effect is to effectively
+disable automatic dependency tracking.
@item @code{no-dist}
@cindex Option, @code{no-dist}
(@pxref{User Variables}), @code{AM_CPPFLAGS} is the Automake variable,
and @code{mumble_CPPFLAGS} is the variable specific to the
@code{mumble} target (we call this a per-target variable,
-see @ref{Program and Library Variables}).
+@pxref{Program and Library Variables}).
Automake always uses two of these variables when compiling C sources
files. When compiling an object file for the @code{mumble} target,
We recommend against this, because this is error prone. For instance
if you add such a rule to the first example, it will break the day you
decide to remove @code{foo_CFLAGS} (because @file{foo.c} will then be
-compiled as @file{foo.o} instead of @file{foo-foo.o}, see @ref{renamed
+compiled as @file{foo.o} instead of @file{foo-foo.o}, @pxref{renamed
objects}). Also in order to support dependency tracking, the two
@file{.o}/@file{.obj} extensions, and all the other flags variables
involved in a compilation, you will end up modifying a copy of the
distributed should appear in @code{DIST_SUBDIRS}, but the manual
describes this as a temporary ugly hack (today extra directories should
also be listed in @code{EXTRA_DIST}, and @code{DIST_SUBDIRS} is used
-for another purpose, see @ref{Conditional Subdirectories}).
+for another purpose, @pxref{Conditional Subdirectories}).
@item 1995-11-26 Automake 0.21
git://sourceware.org / automake.git / commitdiff