- * WARNING: New versioning scheme for Automake.
-
- - Beginning with the release 1.13.2, Automake has started to use a
- more rational versioning scheme, that should allow users to know
- which kind of changes can be expected from a new version, based
- on its version number.
-
- + Micro releases (e.g., 1.13.3, 2.0.1, 3.2.8) introduce only bug
- and regression fixes and documentation updates; they should not
- introduce new features, nor any backward-incompatibility (any
- such incompatibility would be considered a bug, to be fixed with
- a further micro release).
-
- + Minor releases (e.g., 1.14, 2.1) can introduce new backward
- compatible features; the only backward-incompatibilities allowed
- in such a release are new *non-fatal* deprecations and warnings,
- and possibly fixes for old or non-trivial bugs (or even inefficient
- behaviours) that could unfortunately have been seen and used by
- some as "corner case features". Possible disruptions caused by
- this kind of fixes should hopefully be quite rare, and their
- effects limited in scope.
-
- + Major versions (now expected to be released every 18 or 24 months,
- and not more often) can introduce new big features (possibly with
- rough edges and not-fully-stabilized APIs), removal of deprecated
- features, backward-incompatible changes of behaviour, and possibly
- major refactorings (that, while ideally transparent to the user,
- could introduce new bugs). Incompatibilities should however not
- be introduced gratuitously and abruptly; a proper deprecation path
- should be duly implemented in the preceding minor releases.
-
- - According to this new scheme, the next major version of Automake
- (the one that had previously been labelled as "1.14") will actually
- become "Automake 2.0". Automake 1.14 has already been released as
- the last minor release, and the present one is a bug-fixing release
- following up on that one.
-
- - See discussion about automake bug#13578 for more details and
- background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
-
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
+New in 2.0:
+
+* 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'. Put in another way, Automake 2.0
+ and later will *unconditionally* behave as older Automake versions did
+ when the 'subdir-objects' option was given.
+
+* Aclocal search path:
+
+ - Third-party m4 files located in the system-wide aclocal directory,
+ as well as in any directory listed in the ACLOCAL_PATH environment
+ variable, now take precedence over "built-in" Automake macros.
+ For example, assuming Automake is installed in the '/usr/local'
+ hierarchy, a definition of the AM_PROG_VALAC macro found in file
+ (say) '/usr/local/share/aclocal/my-vala.m4' should take precedence
+ over the same-named automake-provided macro, as defined in file
+ '/usr/local/share/aclocal-2.0/vala.m4'.
+
+* Obsolescent features flagged:
+
+ - Use of the special makefile variable 'ACLOCAL_AMFLAGS' is deprecated.
+ To specify locations of extra m4 files, the 'AC_CONFIG_MACRO_DIR' or
+ 'AC_CONFIG_MACRO_DIRS' (the latter introduced with autoconf 2.70)
+ should be used instead. And use of the '--install' aclocal option in
+ 'ACLOCAL_AMFLAGS' has proved to be a bad idea anyway -- see automake
+ bug#9037.
+
+* Obsolete features removed:
+
+ - Support for the long-deprecated name 'configure.in' for the Autoconf
+ input file has been removed altogether. Just use the modern name
+ 'configure.ac' instead.
+
+ - Support for the long-obsolete variable $(ACLOCAL_M4_SOURCES) has
+ been removed. It should be safe to simply remove any definition
+ of it you have in your Makefiles.
+
+* Removed support for obsolete platforms:
+
+ - Support for automatic dependency tracking with the SGI C/C++ compilers
+ on IRIX has been removed. The SGI depmode had been reported broken
+ "in the wild" already, and we don't think investing time in debugging
+ and fixing it would have been worthwhile, especially considering that
+ SGI has last updated those compilers in 2006, and is expected to retire
+ support for them in December 2013:
+ <http://www.sgi.com/services/support/irix_mips_support.html>
+
+ - Support for DJGPP on MS-DOS and/or Windows 95/98/ME has been removed.
+ Note that both Cygwin and MSYS/MinGW on modern Windows versions will
+ continue to be fully supported.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
* WARNING: Future backward-incompatibilities!
- Makefile recipes generated by Automake 2.0 will expect to use an
projects / thirdparty / automake.git / commitdiff
