4.7 Making proper use of AC_LIBOBJ

Source files that provide a replacement should be only compiled on the platforms that need this replacement. While it is actually possible to compile a .c file whose contents is entirely #ifdef’ed out on the platforms that don’t need the replacement, this practice is discouraged because

• It makes the build time longer than needed, by invoking the compiler for nothing.
• It produces a .o file that suggests that a replacement was needed.
• Empty object files produce a linker warning on some platforms: MSVC.

The typical idiom for invoking AC_LIBOBJ is thus the following, in the module description:

if test $HAVE_FOO = 0 || test $REPLACE_FOO = 1; then
  AC_LIBOBJ([foo])
  gl_PREREQ_FOO
fi

Important: Do not place AC_LIBOBJ invocations in the Autoconf macros in the m4/ directory. The purpose of the Autoconf macros is to determine what features or bugs the platform has, and to make decisions about which replacements are needed. The purpose of the configure.ac and Makefile.am sections of the module descriptions is to arrange for the replacements to be compiled. Source file names do not belong in the m4/ directory.

When an AC_LIBOBJ invocation is unconditional, it is simpler to just have the source file compiled through an Automake variable augmentation: In the Makefile.am section write

lib_SOURCES += foo.c

When a module description contains an AC_LIBOBJ([foo]) invocation, you must list the source file lib/foo.c in the Files section. This is needed even if the module depends on another module that already lists lib/foo.c in its Files section – because your module might be used among the test modules (in the directory specified through ‘--tests-base’) and the other module among the main modules (in the directory specified through ‘--source-base’), and in this situation, the AC_LIBOBJ([foo]) of your module can only be satisfied by having foo.c be present in the tests source directory as well.