From: Stefano Lattarini Date: Tue, 24 Dec 2013 14:31:02 +0000 (+0100) Subject: Merge branch 'minor' X-Git-Tag: v1.16~61 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=22a496d84271b2fa25c0d22a233dde4a3eee9ca3;p=thirdparty%2Fautomake.git Merge branch 'minor' * minor: NEWS: stop reporting "new" Automake versioning scheme post-release: micro version bump to 1.14.1a devel version release: stable micro release 1.14.1 HACKING: minor clarification tests: make install-info-dir.sh print more debugging info tests: remove too-brittle test tap-realtime.sh maintainer: am-ft: add option to cater to clock skews sync: update INSTALL, config.guess and config.sub from upstream TAP driver: cosmetic fixes Signed-off-by: Stefano Lattarini --- 22a496d84271b2fa25c0d22a233dde4a3eee9ca3 diff --cc NEWS index ab351fe5c,5cc001977..470a33e53 --- a/NEWS +++ b/NEWS @@@ -1,103 -1,3 +1,61 @@@ +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: + + + - 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: 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: - - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - * WARNING: Future backward-incompatibilities! - Makefile recipes generated by Automake 2.0 will expect to use an