# Any AC related macros can be viewed by autoconf‘s --trace command, quick and simple autoconf -t AC_SUBST autoconf -t ‘AC_DEFINE:[email protected]‘
some frequently used AC macros:
AC_INIT :must
AC_OUTPUT :must
AC_PREREQ :determine ac version so that needed features are included
AC_CONFIG_SRCDIR :determine certain files actually exist
AC_CONFIG_AUX_DIR :use auxiliary build tools (e.g., install-sh, config.sub, config.guess, Cygnus configure, Automake and Libtool scripts, etc.)
AC_REQUIRE_AUX_FILE :determine the stated aux file does exist in the AUX_DIR defined above
AC_CONFIG_MACRO_DIR :usually be m4. specify location of additional local ac macros ( additonal ‘ACLOCAL_AMFLAGS = -I m4 --install‘ be in top-level Makefile.am )
-----
Comments:
autoconf: dnl does not introduce comment in generated configure script, however # intros comment in generated configure script
automake: ## does not introduce comment in generated Makefiles, however # intros comment in generated configure script
-----
AC_OUTPUT :generates config.status and launch it. Call once at the end of configure.ac. (config.status performs based on AC_CONFIG_FILES, AC_CONFIG_HEADERS, AC_CONFIG_COMMANDS, AC_CONFIG_LINKS, AC_CONFIG_SUBDIRS)
AC_CONFIG_ITEMS(tag..., [commands], [init-cmds]) :ITEMS to be one of FILES/HEADERS/COMMANDS/LINKS/SUBDIRS. for FILES/HEADERS, tag to be form like output:input1:input2:.., if no input file specified, the output.in is default. Length of file generated under 2000 lines should be safe. commands are run each time tag file is created. all vars initiated in init-cmds are in the same pool, thus they affect each other.
AC_SUBST :all variables declared with AC_SUBST in configure.ac, and exist in the form of @[email protected] should be replaced in Makefile.in or any other input files AC_CONFIG_FILES when generating output file. Other @[email protected] left unchanged.
Note: any configure/makefile rules for building and installation should not use any utilities directly except these:
awk cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true
The Makefile rules for building and installation can also use compilers and related programs, but should do so via make
variables so that the user can substitute alternatives. Here are some of the programs we mean:
ar bison cc flex install ld ldconfig lex make makeinfo ranlib texi2dvi yacc
Use the following make
variables to run those programs:
$(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX)
$(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC)
other utilities that can be used via Make are:
chgrp chmod chown mknod
------
from here, quotes:
FLAGS related: Debugging and optimization options for the C compiler. If it is not set in the environment when configure runs, the default value is set when you call AC_PROG_CC
(or empty if you don‘t). configureuses this variable when compiling or linking programs to test for C features.
If a compiler option affects only the behavior of the preprocessor (e.g., -Dname), it should be put into CPPFLAGS
instead. If it affects only the linker (e.g., -Ldirectory), it should be put into LDFLAGS
instead. If it affects only the compiler proper, CFLAGS
is the natural home for it. If an option affects multiple phases of the compiler, though, matters get tricky. One approach to put such options directly into CC
, e.g., CC=‘gcc -m64‘
. Another is to put them into both CPPFLAGS
and LDFLAGS
, but not into CFLAGS
.
CXXFLAGS: Debugging and optimization options for the C++ compiler. It acts like CFLAGS
, but for C++ instead of C.
LDFLAGS: Options for the linker. If it is not set in the environment when configure runs, the default value is empty. configure uses this variable when linking programs to test for C, C++, Objective C, Objective C++, Fortran, and Go features. This variable‘s contents should contain options like -s and -L that affect only the behavior of the linker. Please see the explanation of CFLAGS
for what you can do if an option also affects other phases of the compiler. Don‘t use this variable to pass library names (-l) to the linker; use LIBS
instead.
LIBS: -l options to pass to the linker. The default value is empty, but some Autoconf macros may prepend extra libraries to this variable if those libraries are found and provide necessary functions, see Libraries. configure uses this variable when linking programs to test for C, C++, Objective C, Objective C++, Fortran, and Go features.
Sometimes package developers are tempted to set user variables such as CFLAGS
because it appears to make their job easier. However, the package itself should never set a user variable, particularly not to include switches that are required for proper compilation of the package. Since these variables are documented as being for the package builder, that person rightfully expects to be able to override any of these variables at build time. If the package developer needs to add switches without interfering with the user, the proper way to do that is to introduce an additional variable. Automake makes this easy by introducing AM_CFLAGS
(see Flag Variables Ordering), but the concept is the same even if Automake is not used. (Sansna Note: NET-SNMP‘s configure.d/ dir contain ac scripts which sets CFLAGS/LDFLAGS and so on.. in that case, the package builder can only use CFLAGS += "..." to add flags)
------