Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Back: Output from macros
Forward: Macro interface
 
FastBack: Macro interface
Up: Guidelines for writing macros
FastForward: Implementation specifics
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

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 use C and STRUCT as components of its name.

`C'
Tests related to constructs of the C programming language.
`DECL'
Tests for variable declarations in header files.
`FUNC'
Tests for functions present in (or absent from) libraries.
`HEADER'
Tests for header files.
`LIB'
Tests for libraries.
`PATH'
Tests to discover absolute filenames (especially programs).
`PROG'
Tests to determine the base names of programs.
`STRUCT'
Tests for definitions of C structures in header files.
`SYS'
Tests for operating system features, such as restartable system calls.
`TYPE'
Tests for built-in or declared C data types.
`VAR'
Tests for C variables in libraries.

Some examples of macro names formed in this way include:

`AC_PROG_CC'
A test that looks for a program called cc.

`AC_C_INLINE'
A test that discovers if the C keyword inline is recognized.

`bje_CXX_MUTABLE'
A test, written by "bje", that discovers if the C++ keyword mutable is recognized.


This document was generated by Gary V. Vaughan on February, 8 2006 using texi2html

 
 
  Published under the terms of the Open Publication License Design by Interspire