GNU Autoconf: Intro

# Any AC related macros can be viewed by autoconf's --trace command, quick and simple
autoconf -t AC_SUBST
autoconf -t 'AC_DEFINE:$@'

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 @variables@ should be replaced in Makefile.in or any other input files AC_CONFIG_FILES when generating output file. Other @variables@ 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 makevariables 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 CPPFLAGSinstead. 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)

------

Automatic remaking: from here, quotes: (be sure not copy these lines directly into our own repo)

$(srcdir)/configure: configure.ac aclocal.m4
             cd '$(srcdir)' && autoconf
     
     # autoheader might not change config.h.in, so touch a stamp file.
     $(srcdir)/config.h.in: stamp-h.in
     $(srcdir)/stamp-h.in: configure.ac aclocal.m4
             cd '$(srcdir)' && autoheader
             echo timestamp > '$(srcdir)/stamp-h.in'
     
     config.h: stamp-h
     stamp-h: config.h.in config.status
             ./config.status
     
     Makefile: Makefile.in config.status
             ./config.status
     
     config.status: configure
             ./config.status --recheck

-------

Writing AC_CONFIG_HEADERS templdates: from here, quotes:

Your distribution should contain a template file that looks as you want the final header file to look, including comments, with #undef statements which are used as hooks. For example, suppose your `configure.ac' makes these calls:

AC_CONFIG_HEADERS([conf.h]) AC_CHECK_HEADERS([unistd.h])

Then you could have code like the following in `conf.h.in'. On systems that have `unistd.h', configure will `#define' `HAVE_UNISTD_H' to 1. On other systems, the whole line will be commented out (in case the system predefines that symbol).

/* Define as 1 if you have unistd.h. */ #undef HAVE_UNISTD_H

Pay attention that `#undef' is in the first column, and there is nothing behind `HAVE_UNISTD_H', not even white spaces. You can then decode the configuration header using the preprocessor directives:

#include <conf.h> #if HAVE_UNISTD_H # include <unistd.h> #else /* We are in trouble. */ #endif

The use of old form templates, with `#define' instead of `#undef' is strongly discouraged. Similarly with old templates with comments on the same line as the `#undef'. Anyway, putting comments in preprocessor macros has never been a good idea.

Since it is a tedious task to keep a template header up to date, you may use autoheader to generate it, see 4.8.2 Using autoheader to Create `config.h.in'.

And to note that the config.h file does not need to be created manually, if specified in configure.ac that AC_CONFIG_HEADERS(conf.h), then autoconf will use autoheader to create conf.h.in automatically (update based).

------

AC_CONFIG_LINKS:

this call:

          AC_CONFIG_LINKS([host.h:config/$machine.h
                          object.h:config/$obj_format.h])

creates in the current directory host.h as a link tosrcdir/config/$machine.h, and object.h as a link to srcdir/config/$obj_format.h.

The tempting value ‘.’ for dest is invalid: it makes it impossible for ‘config.status’ to guess the links to establish.

One can then run:

          ./config.status host.h object.h

to create the links.

------

AC_CHECK_ITEMS : the items can be func/types/libs/files/header/decl, paramters in the form of (target, [if-cond], [otherwise-cond] ..)

------

Some notes over header:

limit.h

inttypes.h > stdint.h

linux/irda.h : linux/types.h sys/socket.h (':' means requires)

linux/random.h: linux/types.h

...

stdlib.h: stdio.h

particular header check macros:

AC_CHECK_HEADER_STDBOOL

AC_HEADER_ASSERT

AC_HEADER_STDC (obsolete) : newer program check on a file basis, not as a whole

AC_TYPE_INT8_T: define INT8_T if int8_t is usable.

-------

autom4te.cache as its name implies is a cache of previous processings. With it speedup about 30%, but autotools can work without it completly.

debugging ac? set -x; compare working/un-working version; bashdb ..

------

According to here, quotes:

Suffix rules are the old-fashioned way of defining implicit rules for make.

For example, ‘.c’ and ‘.o’ are both on the default list of known suffixes. Therefore, if you define a rule whose target is ‘.c.o’, make takes it to be a double-suffix rule with source suffix ‘.c’ and target suffix ‘.o’. Here is the old-fashioned way to define the rule for compiling a C source file:

.c.o:
        $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

Add suffixes which can be used, by:

.SUFFIXES: .hack .win

clear all suffixes, by:

.SUFFIXES:

-----

转载于:https://www.cnblogs.com/sansna/p/8513641.html