As for this code snippet:

if test "x$enable_maintainer_mode" = xyes; then
    if test -z "$PERL"; then
        AC_MSG_ERROR([perl not found])

# This should be checked before AC_PROG_CC
if test "x$CFLAGS" = x; then

if test "x$host_cpu" = xx86_64; then
    CFLAGS="-m32 $CFLAGS"

I can't find any information on the three variable that is being tested (x$enable_maintainer_mode, x$CFLAGS, x$host_cpu). Are these variable generated after executing the macro AM_MAINTAINER_MODE? If so, where can I find more information about them?

Also, what's the purpose of the AM_MAINTAINER_MODE mode?

From my understanding, it's disabled by default:

  • If a user runs 'configure' and all dependencies are NOT met (Automake version, tools, libraries, etc.), it with terminate and will not proceed further.
  • If a user runs 'configure' and all dependencies are met, it creates and runs the config.status script which generates the 'make' files
  • A user can override this setting with the –enable-maintainer-mode option. This will allows them to modify different Autotool files (such as configure.ac, Makefile.am) and the build system will try to regenerate the files that need to be updated to reflect these changes (Autotools will look for any outdated files and update them accordingly).

I can see why disabling this mode may be preferable. Any reasons why'd you'd want to enable this feature?


The general idea behind AM_MAINTAINER_MODE is to two ways of working with projects: one where the user “only” wants to build and install the project (consuming a source-based artifact for installation), and perhaps make changes to the project’s code without touching its build system, and the other where the user wants any change made anywhere in the project to be reflected in the build output.

Thus when AM_MAINTAINER_MODE is disabled, files such as configure, Makefile.in etc. aren’t rebuilt even if their corresponding source file (configure.ac, Makefile.am etc.) is changed. The supposed advantage of this is that it avoids requiring users to have the necessary build tools, and it avoids having to deal with changes to the tools themselves (ask anyone who’s tried to rebuild an old, complex project using current autotools). The disadvantage is that changes made to certain files are ignored, so users need to make sure that all the appropriate files are updated, manually... (This is one reason why many patches you see on the Internet include changes to Makefile.am and Makefile.in and sometimes even Makefile.)

The advantage of enabling AM_MAINTAINER_MODE is that all changes made to files are taken into account. The disadvantage is that the user needs to know what the real source files are: if you make a change to Makefile.in and rebuild with maintainer mode, you might lose your changes!

The general consensus nowadays seems to be that rebuilding from the real source is better, and that maintainer mode isn’t all that good an idea. (The automake FAQ provides references.) This doesn’t mean that all users suddenly need to have all the tools required to rebuild everything; if a project ships the generated files in its release artifacts, as long as the timestamps are good then users won’t need to rebuild them.

  • You mentioned that user's need to know the real source files if you make changes to the Makefile.in. Does this mean knowing the source file(s) and location, and updating the respective Makefile.am? – supmethods Oct 12 '18 at 14:18
  • I meant that users need to know that Makefile.in isn’t a source file, it’s generated from Makefile.am, and so instead of modifying Makefile.in, they should modify Makefile.am. – Stephen Kitt Oct 12 '18 at 14:20

The variables here are shell variable with an 'x' added to it.

x$enable_maintainer_mode will be set to xyes when you pass the option --enable-maintainer-mode to configure and xno when you pass the option --disable-maintainer-mode to configure. Otherwise, the variable will be 'x'.

The variable CFLAGS can be set through ./configure CFLAGS='compiler flag options'. Otherwise, if nothing is set, then the default_CFLAGS=yes. x$host_cpu can be obtained from the AC_CANONICAL_HOST macro. Here's a related link for the host_cpu and AC_CANONICAL_HOST macro call.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.