23.3.4 Naming macros
Just like functions in a C program, it's important to choose a good name
for your Autoconf macros. A well-chosen name helps to unambiguously
describe the purpose of the macro. Macros in M4 are all named
within a single namespace and, thus, it is necessary to follow a
convention to ensure that names retain uniqueness. This reasoning goes
beyond just avoiding collisions with other macros--if you happen to
choose a name that is already known to M4 as a definition of any
kind, your macro's name could be rewritten by the prior definition
during macro processing.
One naming convention has emerged--prefixing each macro name with the
name of the package that the macro originated in or the initials of the
macro's author. Macros are usually named in a hierarchical fashion,
with each part of the name separated by underscores. As you move
left-to-right through each component of the name, the description
becomes more detailed. There are some high-level categories of macros
suggested by the Autoconf manual that you may wish to use when forming a
descriptive name for your own macro. For example, if your macro tries
to discover the existence of a particular C structure, you might wish to
STRUCT as components of its name.
- Tests related to constructs of the C programming language.
- Tests for variable declarations in header files.
- Tests for functions present in (or absent from) libraries.
- Tests for header files.
- Tests for libraries.
- Tests to discover absolute filenames (especially programs).
- Tests to determine the base names of programs.
- Tests for definitions of C structures in header files.
- Tests for operating system features, such as restartable system calls.
- Tests for built-in or declared C data types.
- Tests for C variables in libraries.
Some examples of macro names formed in this way include:
- A test that looks for a program called
- A test that discovers if the C keyword
inline is recognized.
- A test, written by "bje", that discovers if the C++ keyword
mutable is recognized.