Re: M4 stock macros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 28, 2021 at 1:08 PM DUDZIAK Krzysztof
<krzysztof.dudziak@xxxxxxxxxxxxxxx> wrote:
> I aim to gain bit more high-level overview regarding stock M4 macros
> provider and consumer parties.  It is about autotools stock M4 macros.
>
> Used terms:
> to consume = to expand
> to provide = to install from particular autotool package
>
> Is understanding right in all points below?
> These properties have accumulative effect, add to each other.
> Autotools suite supportive tools, e.g. autom4te, are not in focus here.

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’.

> * autoconf as major M4 macros provider installs those to developer
>   machine for use in projects developed on same machine, macro name
>   AC_ prefix

Yes, these are what I referred to as the “built-in library” above.
Note that not all of the macros have an AC_ prefix; m4_, AS_, AU_, and
AH_ are also used.

> * autoconf is also major consumer of M4 macros - autoconf time

autoconf is the *only* program that “consumes” macros in the sense you
defined it.  Several other programs “trace” macros.  I would recommend
saying only “expand” or “trace”, not “consume”.

> * autoconf consumes macros installed by itself

Yes.

> * automake package comes with a set of own macros, these are
>   installed also to developer machine for same high-level purpose as
>   macros provided by autoconf, , macro name AM_ prefix

Yes.  Again, other prefixes may also be used.

> * automake calls autoconf at automake time to consume macros placed
>   to configure.ac

No.  automake does run autoconf as a subprocess, but to *trace*
macros, not to expand them.

> * automake consumes macros installed by itself, automake manual,
>   ch. 6.2
> * there are macros provided by autoconf yet consumed at automake
>   time, automake manual, ch. 6.2
> * there are macros consumed only at automake time

Automake does not expand macros.

> * there are macros provided by automake yet consumed at autoconf
>   time, automake manual, ch. 6.4

Yes.

> * there are macros consumed only at autoconf time

All macros are expanded at autoconf time, and not at any other time.

> Also question arises if there are further major properties
> completing picture at shown level.

I do not have a clear understanding of the “picture” you have in mind,
so I don’t know what to add here.

zw





[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux