This file lists the major changes and differences between mainstream Automake and Automake-NG. Be aware that there is likely a plethora of other minor differences and incompatibilities *not* listed here. Automatic dependency tracking support ===================================== * The generated Makefile.in files use "-include", not "include", to read the '.Po' files containing automatically computed dependency information. * We unconditionally assume that the "include" and "-include" directives can be used in the generated Makefiles. Accordingly, the internal m4 macro 'AM_MAKE_INCLUDE' and AC_SUBST'd variables 'am__include' and 'am__quote' have been removed. * The makefile fragments files containing automatically computed dependency information are created at make runtime by Makefile recipes, not at configure time by config.status. Accordingly, the special config.status argument 'depfiles' is not supported anymore. Silent rules ============ * The silent rules support has been simplified to take advantage of more GNU make features. Among other things, the AC_SUBST'd variables '@AM_V@' and'@AM_DEFAULT_V@' have been removed. Now, when defining uses custom silent rules, you should do something like: # Modern correct way. pkg_verbose = $(pkg_verbose/$(V)) pkg_verbose/0 = @echo PKG-GEN $@; pkg_verbose/1 = while the old idiom would have been something like: # Old obsolete way, won't work anymore. pkg_verbose = $(pkg_verbose_@AM_V@) pkg_verbose_ = $(pkg_verbose_@AM_DEFAULT_V@) pkg_verbose_0 = @echo PKG-GEN $@; Warnings and diagnostic ======================= * Automake does not warn anymore about: - non-POSIX variable names, like "$(dash-separated)" or "$(stem/base)"; - nested variable expansions, like "$(foo$(V))"; - variable definitions with indirections, like "var$(i) = value"; - calls to make functions, whether built-in ones like "$(wildcard *.c)" or user-defined ones like "$(call my-func, arg1, arg2)". - pattern rules in GNU make style ("%.o: %.c"). - variable definitions with ":=", as in "foo := $(immediate-evaluation)". - some issues specific to BSD make. * The 'portability-recursive' warning category is obsolete, and has been removed. * Automake-NG is less smart than mainline Automake in detecting some kind of possible typos or suspicious usages at automake runtime. This is due to the fact that more processing and logic takes place in the generated Makefiles rather than in the automake script, so that the latter has access to less context and information. * Diagnostic about possible typos in '_SOURCES', '_LIBADD, '_LDFLAGS', '_LDADD' and '_DEPENDENCIES' variables is now done at make runtime rather than at automake runtime. In case some (or all) such diagnostic is undesired, it can be silenced by adding the affected variables to the 'AM_VARTYPOS_WHITELIST' variable, as in: bin_PROGRAMS = cp mv copy_LDADD = -lselinux -lrt -acl cp_LDADD = $(copy_LDADD) mv_LDADD = $(copy_LDADD) # Without this, the generated Makefile would complain that # no program or library has 'copy' as canonical name. AM_VARTYPOS_WHITELIST = copy_LDADD Compilation and Object Files ============================= * If a source file is placed in a subdirectory, the corresponding compiled object will always be put into the subdirectory named after the source file, rather than in the current directory. For instance, 'src/file.c' and 'src/file.f90' will be compiled to 'src/file.o', and 'sub/dir/mu.cc' will be compiled to 'sub/dir/mu.o'. That is, Automake-NG will unconditionally behave as Automake would do if its 'subdir-objects' option were active. Serial testsuite harness (obsolescent) ====================================== * The $(TESTS) and $(XFAIL_TESTS) variables are no longer rewritten for $(EXEEXT) appending. The use of compiled programs in $(TESTS) and $(XFAIL_TESTS) still works as before though, even on systems where $(EXEEXT) is non-empty. Parallel testsuite harness ========================== * Automake no longer automatically generate the definition of 'LOG_COMPILE' variables. These have always been meant for internal use only anyway. * The $(TESTS) and $(XFAIL_TESTS) variables are no longer rewritten for $(EXEEXT) appending. The use of compiled programs in $(TESTS) still works as before though, even on systems where $(EXEEXT) is non-empty, thanks to a careful use of pattern rules. * The new implementation of the parallel-tests harness tries to defer as much as possible processing on the $(TESTS), $(XFAIL_TESTS) and $(TEST_EXTENSIONS) variable at make runtime, rather than doing it at automake time. This has several positive effects (described below), but also entails a minor annoyance: due to implementation reasons, the 'test-driver' auxiliary script is now always required and distributed, even if no test script actually uses it as its LOG_DRIVER script. This is not a big deal in practice, since as of today, all the real world packages out there actually use 'test-driver' for most (if not all) of their tests (the introduction of TAP support in mainstream automake being too recent for those packages to have had time to phase out their protocol-less tests, assuming they wanted to -- which is usually not the case either). * The parallel testsuite harness realizes whether an entry of $(TESTS) start with $(srcdir) (as in "TESTS = $(srcdir)/foo.test"), and manages to correctly create the corresponding '.log' and '.trs' files in the build directory rather than in the source directory. * The contents of $(TESTS) are mostly analyzed at make runtime rather than at automake runtime, so that it is now possible to use GNU make advanced features (like specific builtins or user-defined functions) in the definition of $(TESTS); for example, the following should now work as expected: TESTS = $(wildcard $(srcdir)/t[0-9][0-9]*.sh) * The contents of $(TEST_EXTENSIONS) are mostly analyzed at make runtime rather than at automake runtime, so that it is now possible to use Automake conditionals and GNU make advanced features in the definition of $(TEST_EXTENSIONS); for example, the following should now work as expected: TEST_EXTENSIONS = $(sort $(suffix $(TESTS))) if SUPPORT_SHELL_TESTS TEST_EXTENSIONS += .sh endif * We are more liberal and lenient in accepting TEST_EXTENSIONS entries: it's enough that they start with a dot to be considered valid. However, using overly "funny" characters (like '!' or '@') could cause problems, so the user is still advised to limit himself to the use of alphanumeric characters, plus eventually '.', '-', and '_'. * Errors about invalid content of $(TEST_EXTENSIONS) are reported at make runtime, not auto Automake runtime. * It is no longer possible to override TEST_LOGS at make runtime as a mean to redefine the list of tests to be run. # This won't work anymore! make check TESTS_LOGS="foo.log bar.log baz.log" But it's still possible do so overriding TESTS at make runtime; and in this case (as was the case for TEST_LOGS overriding), it is not necessary to specify the extensions of the tests to be run: # This will work even if complete names of the tests are (say) # "foo.test", "bar.test$(EXEEXT)" and "baz$(EXEEXT)". make check TESTS="foo bar baz" * The use of 'RECHECK_LOGS' is no longer supported. Thus, to lazily re-run only the tests whose '.trs' or '.log' files are out-of-date, one must now use: make check AM_LAZY_CHECK=yes # New valid API. instead of: make check RECHECK_LOGS="" # Old API, won't work anymore. * Per-suffix dependencies for test cases can be specified through variables "_LOG_DEPENDENCIES" (this being simply "LOG_DEPENDENCIES" for suffix-less tests). Distribution ============ * "Bare" wildcards are no longer usable in $(EXTRA_DIST): EXTRA_DIST = $(srcdir)/doc/*.txt # This won't work anymore. You'll have to use the $(wildcard) GNU make builtin instead, as in: EXTRA_DIST = $(wildcard $(srcdir)/doc/*.txt) # Good. or even (for a better support of VPATH builds): EXTRA_DIST = $(wildcard doc/*.txt $(srcdir)/doc/*.txt) # Better. * The make variables $(DISTFILES), $(DIST_COMMON), $(DIST_SOURCES) and $(DIST_ARCHIVES) had never been documented in mainline Automake, and were always intended to be internal variables. But that was not clear from their names. So we have renamed rename like this: DISTFILES => am.dist.all-files DIST_COMMON => am.dist.common-files DIST_SOURCES => am.dist.sources DIST_ARCHIVES => am.dist.default-archives Do not use any of these variables in your Makefiles! * Support for distribution archived in the '.shar.gz' and '.tar.Z' formats have been removed; and with them the targets 'dist-shar' and 'dist-tarZ'. * The API to specify the formats of distribution tarballs has been changed completely. Instead of using the various 'dist-*' automake options, the developer is now expected to specify the default formats of its distribution tarballs with the special variable AM_DIST_FORMATS; for example, where once would have been: AM_INIT_AUTOMAKE([dist-bzip2 dist-zip]) now it must be: AM_DIST_FORMATS = gzip bzip2 zip and similarly, where once would have been: AUTOMAKE_OPTIONS = no-dist-gzip dist-bzip2 dist-xz now is it simply: AM_DIST_FORMATS = bzip2 xz * The various 'dist-*' targets (dist-gzip, dist-xz, dist-lzip, dist-bzip2 and dist-gz) has been removed. If the user wants to generate tarballs for formats not specified by the default AM_DIST_FORMATS, he can simply override that variable dynamically: # Will generate a '.zip' archive and a '.tar.xz' archive, and not # further ones. make dist AM_DIST_FORMATS='zip xz' * The DIST_TARGETS variable has been removed (as a side-effect of the previous change). Texinfo ======= * Extension-less info files are no longer supported (mainline Automake has been warning against them since version 1.13.2, albeit it continues to support them for backward-compatibility). * The only accepted suffix for input Texinfo files is now '.texi'; the once-accepted values '.txi' and '.texinfo' are no longer handled, and their use will trigger an error (mainline Automake has been warning against these suffixes since version 1.13.2, albeit it continues to support them for backward-compatibility). * Disabling distribution of generated '.info' files be re-defining the 'dist-info' target, as in: dist-info: @: (which has always been an undocumented hack in Automake) no longer works. We are still considering whether to make an equivalent capability available with a new, cleaner and documented API. Obsolete Features Removed ========================= * If the sources for a target library like 'libfoo.a' or 'libbar.la' are not explicitly specified, mainline Automake looks also (respectively) for the files 'libfoo_a.c' or 'libbar_la.c' as possible default sources. Such a behaviour is deprecated though, and is present only for the sake of backward-compatibility. Automake-NG has thus dropped the behaviour, and will only look for (respectively) 'libfoo.c' and 'libbar.c' as possible default sources. * Automake-NG has removed automatic handling and distribution of the obsolescent 'acconfig.h', 'config.h.top' and 'config.h.bot' files. One should instead use the modern macros 'AH_VERBATIM' and 'AH_TEMPLATE', as recommended in the Autoconf manual (as of Autoconf 2.69, chapter "Obsolete Constructs", section "acconfig.h"). * The 'mkinstalldirs' script is no longer installed, distributed, nor provided; its same effects can be obtained by "install-sh -d" instead. Similarly, the $(mkinstallscripts) make variable is no longer defined; one should use $(MKDIR_P) instead. * The Automake-defined internal make variable '$(ACLOCAL_M4)' has been renamed to '$(am.remake.aclocal-m4)', and should be considered an internal detail. * The variables $(target_triplet), $(host_triplet) and $(build_triplet), which were redundant because aliases respectively for the variables $(target), $(host) and $(build), have been removed. Simply use this latter variables. * Threaded automake execution (as triggered by $AUTOMAKE_JOBS) has been removed altogether. Exporting AUTOMAKE_JOBS to in the environment of Automake will now have no effect. * Support for "maintainer mode" has been removed, and rules to remake maintainer-specific files are now always active. The 'missing' script should till take care of warning users which find themselves in the situation of having to rebuild some maintainer-specific files but missing the relevant maintainer-specific tools (or having too old versions thereof). * The $(RECURSIVE_CLEAN_TARGETS) variable (never documented, and always intended to be an internal detail) has been removed, its content merged into the $(RECURSIVE_TARGETS) variable. Source Files with Unknown Extensions ==================================== * Automake-NG used a much simpler and dumber algorithm that mainline Automake to determine how to build an object associated to a source whose extension in not one of those handled internally by automake. The new algorithm goes like this. For any file listed in a '_SOURCES' variable whose suffix is not recognized internally by automake (in contrast to known suffixes like '.c' or '.f90'), automake will obtain the expected target object file by stripping the suffix from the source file, and appending either '.$(OBJEXT)' or '.lo' to it (which one depends on whether the object is built as part of a program, a static library, or a libtool library). It will then be assumed that the user has defined a rule (either explicit or defined from a pattern rule) which can turn that source file into this corresponding object file. For example, on an input like: bin_PROGRAMS = foo foo_SOURCES = mu.ext1 fu.ext1 zu.ext1 automake will expect that the three objects mu.$(OBJEXT), fu.$(OBJEXT) and zu.$(OBJEXT) are to be used in the linking of the 'foo' program, and that the user has provided proper recipes for all those objects to be built at make time, as well as a link command for linking 'foo'. Here is an example of how those declarations could look like: %.$(OBJEXT): %.ext1 my-compiler -c -o $@ $< foo_LINK = $(CC) -o $@ In this particular case, the idiom above is basically the same one that would be required in mainline automake (apart for the fact that, there, old-fashioned suffix rules should be used instead of pattern rules). To see what is truly changed with the new algorithm, we have to look at a more indirect usage. Mainline Automake follows the chain of user-defined pattern rules to determine how to build the object file deriving from a source file with a custom user extension; for example, upon reading: .zoo.cc: $(preprocess) $< > $@ bin_PROGRAMS = foo foo_SOURCES = bar.zoo *mainline* Automake knows that it has to bring in the C++ support (compilation rules, requirement for AC_PROG_CXX in configure.ac, etc), and use the C++ linker to link the 'foo' executable. But Automake-NG will *no longer follow those implicit chains* of pattern rules; so that the idiom above will have to be re-worked like follows to preserve its intent and behaviour: %.cc: %.zoo: $(preprocess) $< > $@ bin_PROGRAMS = foo # The use of '.cc' is required to let Automake know to bring in # stuff for the handling of C++ compilation, and to use the C++ # linker to build 'foo'. nodist_foo_SOURCES = bar.cc EXTRA_DIST = foo.zoo And there is another major consequence of this change of semantics: now one can no longer use "header files" with extensions unrecognized to Automake; for example, an usage like this will cause errors at make runtime: # Won't work anymore. %.h: %.my-hdr $(preprocess-header) $< >$@ foo_SOURCES = foo.c bar.my-hdr BUILT_SOURCES = bar.h errors that might look like: make[1]: *** No rule to make target 'bar.o', needed by 'zardoz'. Stop. The simple workaround is to place the "non-standard" headers in EXTRA_DIST rather than in a _SOURCES variable: # This will work. %.h: %.my-hdr $(preprocess-header) $< >$@ foo_SOURCES = foo.c foo.h EXTRA_DIST = foo.my-hdr BUILT_SOURCES = foo.h Miscellaneous ============= * Since GNU make is smart enough to correctly pass the values of macros redefined on the command line to sub-make invocations, the "special" variable $(AM_MAKEFLAGS) has been removed, and its content is no more passed to recursive make invocations. * The make variable 'CONFIG_HEADER' had never been documented in mainline Automake, and since when the support for user setting of it has been removed (in favour of the use of the 'AC_CONFIG_HEADERS' autoconf macro in configure.ac), it has been intended as an internal variable only. So we've renamed it to 'AM_CONFIG_HEADERS'. Do not override its value in your Makefiles! * The Automake-generated make variable 'DEFAULT_INCLUDES', used internally in compilation rules and basically never documented in mainline Automake, has been renamed to AM_DEFAULT_INCLUDES, to avoid impinging on the user's namespace. Do not override this variable in your Makefiles! * The Automake-generated clean targets no longer exit successfully if an error occurs while removing a file or directory. * The semantic of $(BUILT_SOURCES) support has been slightly altered; now, the files listed in $(BUILT_SOURCES) will be built not only before the "all", "check" or "install" targets, but before *any* target. ----- Copyright (C) 2012-2015 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see .