Next: Automatic dependency tracking, Previous: Support for Other Languages, Up: Building Programs and Libraries [Contents][Index]
Although the GNU standards allow the use of ANSI C, this can have the effect of limiting portability of a package to some older compilers (notably the SunOS C compiler).
Automake allows you to work around this problem on such machines by de-ANSI-fying each source file before the actual compilation takes place.
If the Makefile.am variable AUTOMAKE_OPTIONS
(see Changing Automake’s Behavior) contains the option ansi2knr
then code to
handle de-ANSI-fication is inserted into the generated
Makefile.in.
This causes each C source file in the directory to be treated as ANSI C.
If an ANSI C compiler is available, it is used. If no ANSI C compiler
is available, the ansi2knr
program is used to convert the source
files into K&R C, which is then compiled.
The ansi2knr
program is simple-minded. It assumes the source
code will be formatted in a particular way; see the ansi2knr
man
page for details.
Support for de-ANSI-fication requires the source files ansi2knr.c
and ansi2knr.1 to be in the same package as the ANSI C source;
these files are distributed with Automake. Also, the package
configure.in must call the macro AM_C_PROTOTYPES
(see Autoconf macros supplied with Automake).
Automake also handles finding the ansi2knr
support files in some
other directory in the current package. This is done by prepending the
relative path to the appropriate directory to the ansi2knr
option. For instance, suppose the package has ANSI C code in the
src and lib subdirs. The files ansi2knr.c and
ansi2knr.1 appear in lib. Then this could appear in
src/Makefile.am:
AUTOMAKE_OPTIONS = ../lib/ansi2knr
If no directory prefix is given, the files are assumed to be in the current directory.
Files mentioned in LIBOBJS
which need de-ANSI-fication will not
be automatically handled. That’s because configure
will generate
an object name like regex.o, while make
will be looking
for regex_.o (when de-ANSI-fying). Eventually this problem will
be fixed via autoconf
magic, but for now you must put this code
into your configure.in, just before the AC_OUTPUT
call:
# This is necessary so that .o files in LIBOBJS are also built via # the ANSI2KNR-filtering rules. LIBOBJS=`echo $LIBOBJS|sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'`
Note that automatic de-ANSI-fication will not work when the package is
being built for a different host architecture. That is because automake
currently has no way to build ansi2knr
for the build machine.
Next: Automatic dependency tracking, Previous: Support for Other Languages, Up: Building Programs and Libraries [Contents][Index]