> These look mostly accurate (small comments below) but I am not sure they > add up to a useful way of thinking about the process of constructing > the various files generated by the autotools. I would describe the > process in terms of which programs read which files: > > - autoconf generates ‘configure’ from ‘configure.ac’, ‘aclocal.m4’, > and autoconf’s built-in library of macros. autoconf is the only > program that actually expands M4 macros. > > - autoheader generates ‘config.h.in’ from the same set of files read > by autoconf. It *traces* the M4 macros used in those files to > determine what they define, but it does not expand them.[*] > > - aclocal determines the set of macros referenced by ‘configure.ac’ > that are *not* part of autoconf’s built-in library, finds their > definitions (looking in several places where they might be > installed on the build machine, and also within the package’s > source code) and copies them into ‘aclocal.m4’. Like autoheader, > it traces macro uses (to learn which third-party macros are needed) > but does not expand them. > > - automake generates ‘Makefile.in’ from ‘Makefile.am’. automake > expects ‘configure.ac’ to be set up in a specific way, including > the use of certain macros provided by automake. It, too, traces > macros in configure.ac (to make decisions about what to put in > ‘Makefile.in’) but does not expand them. > > - autoreconf orchestrates running all of the above programs, and > several others, as necessary. > > [*] Tracing means running the M4 interpreter in an alternative mode. > In this mode, it still reads an input file containing M4 macros, > such as ‘configure.ac’. But instead of expanding those macros and > emitting the resultant text, it emits a machine-parseable list of > invocations of some subset of the macros, with arguments. Tracing > is used by all of the autotools, *except* autoconf, to extract > information from ‘configure.ac’. I see, word myself choose is not working well. Sure, there is significant difference between macro expansion and execution. However, as for me it is still unclear how tracking works up to end. Some entity must take over invocation of subset of macros on list emitted by M4 interpreter when it runs in alternative mode. Maybe suite components those not performing macro expansion, e.g. automake are these. No luck on finding more details regarding M4 interpreter alternative mode in M4 manual. E.g.: In end-result there is machine-parseable list. List would include invocations of some subset of macros. What kind exactly are list items of, invocations performed, invocations to be performed, input, output, log of every invocation, anything else? Which language are operation being invoked in? Analyzing suite components from each tool input-output process perspective leaves open questions in certain areas. The idea is to fill at least certain number of understanding gaps raised this way by applying one more perspective (macro provision and usage). To make this task easier the plan was to consider suite's main components: autconf and automake.
