X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=NEWS;h=1cc00a48c4849229a7753b4dafc87c10c70eb686;hb=6febcd41b3dcf99a89aaf21329c00fdadcd68771;hp=ef1e953fca0414cbf3ed8c0d283a373624d9052b;hpb=6899085918b1673131e5451c39390b76ba273540;p=platform%2Fupstream%2Fautomake.git diff --git a/NEWS b/NEWS index ef1e953..1cc00a4 100644 --- a/NEWS +++ b/NEWS @@ -1,53 +1,371 @@ -New in 1.13.1: +* WARNING: New versioning scheme for Automake. + + - Starting with this version onward, Automake will use an update and + more rational versioning scheme, one that will allow users to know + which kind of changes can be expected from a new version, based on + its version number. + + + Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only + documentation updates and bug and regression fixes; they will + 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 versions (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 developers as "corner case features". Possible disruptions + caused by this kind of fixes should hopefully be quite rare. + + + 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 has until now been labelled as '1.14') will actually + become "Automake 2.0". Automake 1.14 will be the next minor version, + which will introduce new features, deprecations and bug fixes, but + no serious backward incompatibility. + + - See discussion about automake bug#13578 for more details and + background: * WARNING: Future backward-incompatibilities! - - Automake 1.14 will likely require Autoconf 2.70 or later (which is - still unreleased at the moment of writing, but is planned to be - released before Automake 1.14 is). - - - Automake 1.14 will likely drop support for the long-deprecated - 'configure.in' name for the Autoconf input file. You are advised - to use the recommended name 'configure.ac' instead. - - - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will - be removed in Automake 1.14. The $(mkdir_p) make variable and the - @mkdir_p@ substitution will still remain available (as aliases of - $(MKDIR_P)) for the moment, for better backward compatibility; but - you are advised to stop using ASAP. + - Makefile recipes generated by Automake 2.0 will expect to use an + 'rm' program that doesn't complain when called without any non-option + argument if the '-f' option is given (so that commands like "rm -f" + and "rm -rf" will act as a no-op, instead of raising usage errors). + Accordingly, AM_INIT_AUTOMAKE will expand new shell code checking + that the default 'rm' program in PATH satisfies this requirement, and + aborting the configure process if this is not the case. This behavior + of 'rm' is very widespread in the wild, and it will be required in the + next POSIX version: + + + - Automake 2.0 will require Autoconf 2.70 or later (which is still + unreleased at the moment of writing, but is planned to be released + before Automake 2.0 is). + + - Automake 2.0 will drop support for the long-deprecated 'configure.in' + name for the Autoconf input file. You are advised to start using the + recommended name 'configure.ac' instead, ASAP. - The ACLOCAL_AMFLAGS special make variable will be fully deprecated - in Automake 1.14 (where it will raise warnings in the "obsolete" + in Automake 2.0 (where it will raise warnings in the "obsolete" category). You are advised to start relying on the new Automake - support for AC_CONFIG_MACRO_DIRS instead (which is introduced with - this release; see below for more information). - - - Support for IRIX and the SGI C/C++ compilers will be removed in - Automake 1.14: they have seen their last release in 2006, and SGI - is expected to retire support from them in December 2013; see - for - more information. - - - Future versions of Automake might remove support for MS-DOS and - Windows 95/98/ME (support for them was offered by relying on the - DJGPP project). Note however that both Cygwin and MSYS/MinGW on - modern Windows versions will continue to be fully supported. - - - Support for the long-deprecated INCLUDES variable will be removed - altogether in Automake 1.14. The AM_CPPFLAGS variable should be - used instead. + support for AC_CONFIG_MACRO_DIRS instead (which was introduced in + Automake 1.13). + + - Automake 2.0 will remove support for automatic dependency tracking + with the SGI C/C++ compilers on IRIX. The SGI depmode has been + reported broken "in the wild" already, and we don't think investing + time in debugging and fixing is worthwhile, especially considering + that SGI has last updated those compilers in 2006, and is expected + to retire support for them in December 2013: + + + - Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME + (support for them was offered by relying on the DJGPP project). + Note however that both Cygwin and MSYS/MinGW on modern Windows + versions will continue to be fully supported. - Automake-provided scripts and makefile recipes might (finally!) - start assuming a POSIX shell in Automake 1.14. + start assuming a POSIX shell in Automake 2.0. - - Starting from Automake 1.14, third-party m4 files located in the + - Starting from Automake 2.0, third-party m4 files located in the system-wide aclocal directory, as well as in any directory listed in the ACLOCAL_PATH environment variable, will 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 '/usr/local/share/aclocal/my-vala.m4' should take precedence over the same-named automake-provided macro - (defined in '/usr/local/share/aclocal-1.14/vala.m4'). + (defined in '/usr/local/share/aclocal-2.0/vala.m4'). + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New in 1.14: + +* C compilation, and the AC_PROG_CC and AM_PROG_CC_C_O macros: + + - The 'compile' script is now unconditionally required for all + packages that perform C compilation (note that if you are using + the '--add-missing' option, automake will fetch that script for + you, so you shouldn't need any explicit adjustment). + This new behaviour is needed to avoid obscure errors when the + 'subdir-objects' option is used, and the compiler is an inferior + one that doesn't grasp the combined use of both the "-c -o" + options; see discussion about automake bug#13378 for more details: + + + + - The next major Automake version (2.0) will unconditionally turn on + the 'subdir-objects' option. In order to smooth out the transition, + we now give a warning (in the category 'unsupported') whenever a + source file is present in a subdirectory but the 'subdir-object' is + not enabled. For example, the following usage will trigger such a + warning (of course, assuming the 'subdir-objects' option is off): + + bin_PROGRAMS = sub/foo + sub_foo_SOURCES = sub/main.c sub/bar.c + + - Automake will automatically enhance the AC_PROG_CC autoconf macro + to make it check, at configure time, that the C compiler supports + the combined use of both the "-c -o" options. The result of this + check is saved in the cache variable 'am_cv_prog_cc_c_o', and said + result can be overridden by pre-defining that variable. + + - The AM_PROG_CC_C_O can still be called, but that should no longer + be necessary. This macro is now just a thin wrapper around the + Automake-enhanced AC_PROG_CC. This means, among the other things, + that its behaviour is changed in three ways: + + 1. It no longer invokes the Autoconf-provided AC_PROG_CC_C_O + macros behind the scenes. + + 2. It caches the check result in the 'am_cv_prog_cc_c_o'variable, + and not in a 'ac_cv_prog_cc_*_c_o' variable whose exact name + in only dynamically computed at configure runtime (sic!) from + the content of the '$CC' variable. + + 3. It no longer automatically AC_DEFINE the C preprocessor + symbol 'NO_MINUS_C_MINUS_O'. + +* Texinfo support: + + - Automake can now be instructed to place '.info' files generated from + Texinfo input in the builddir rather than in the srcdir; this is done + specifying the new automake option 'info-in-builddir'. This feature + was requested by the developers of GCC, GDB, GNU binutils and the GNU + bfd library. See the extensive discussion about automake bug#11034 + for more details. + + - For quite a long time, Automake has been implementing an undocumented + hack which ensured that '.info' files which appeared to be cleaned + (by e.g. being listed in the CLEANFILES or DISTCLEANFILES variables) + were built in the builddir rather than in the srcdir; this hack was + introduced to ensure better backward-compatibility with packages such + as Texinfo, which did things like: + + info_TEXINFOS = texinfo.txi info-stnd.texi info.texi + DISTCLEANFILES = texinfo texinfo-* info*.info* + # Do not create info files for distribution. + dist-info: + @: + + in order not to distribute generated '.info' files. + + Now that we have the 'info-in-builddir' option that explicitly causes + generated '.info' files to be placed in the builddir, this hack should + be longer necessary, so we deprecate it with runtime warnings. It will + likely be removed altogether in Automake 2.0. + +* Relative directory in Makefile fragments: + + - The special Automake-time substitutions '%reldir%' and '%canon_reldir%' + (and their short versions, '%D%' and '%C%' respectively) can now be used + in an included Makefile fragment. The former is substituted with the + relative directory of the included fragment (compared to the top level + including Makefile), and the latter with the canonicalized version of + the same relative directory: + + bin_PROGRAMS += %reldir%/foo + %canon_reldir%_foo_SOURCES = %reldir%/bar.c + +* Deprecated distribution formats: + + - The 'shar' and 'compress' distribution formats are deprecated, and + scheduled for removal in Automake 2.0. Accordingly, the use of the + 'dist-shar' and 'dist-tarZ' will cause warnings at automake runtime + (in the 'obsolete' category), and the recipes for the Automake-generated + targets 'dist-shar' and 'dist-tarZ' will unconditionally display + (non-fatal) warnings at make runtime. + +* New configure runtime warnings about "rm -f" support: + + - To simplify transition to Automake 2.0, the shell code expanded by + AM_INIT_AUTOMAKE now checks (at configure runtime) that the default + 'rm' program in PATH doesn't complain when called without any + non-option argument if the '-f' option is given (so that commands + like "rm -f" and "rm -rf" act as a no-op, instead of raising usage + error). If this is not the case, + the configure script is aborted, to call the attention of the user + on the issue, and invite him to fix his PATH. The checked 'rm' + behavior is very widespread in the wild, and will be required by + future POSIX version: + + + + The user can still force the configure process to complete even in the + presence of a broken 'rm' by defining the ACCEPT_INFERIOR_RM_PROGRAM + environment variable to "yes". And the generated Makefiles should + still work correctly even when such broken 'rm' is used. But note + that this will no longer be the case with Automake 2.0 though, so, if + you encounter the warning, please report it to us ASAP (and try to fix + your environment as well). + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New in 1.13.4: + +* Bugs fixed: + + - Fix a minor regression introduced in Automake 1.13.3: when two or more + user-defined suffix rules were present in a single Makefile.am, + automake would needlessly include definition of some make variables + related to C compilation in the generated Makefile.in (bug#14560). + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New in 1.13.3: + +* Documentation fixes: + + - The documentation no longer mistakenly reports that the obsolete + 'AM_MKDIR_PROG_P' macro and '$(mkdir_p)' make variable are going + to be removed in Automake 2.0. + +* Bugs fixed: + + - Byte-compilation of Emacs lisp files could fail spuriously on + Solaris, when /bin/ksh or /usr/xpg4/bin/sh were used as shell. + + - If the same user-defined suffixes were transformed into different + Automake-known suffixes in different Makefile.am files in the same + project, automake could get confused and generate inconsistent + Makefiles (automake bug#14441). + For example, if 'Makefile.am' contained a ".ext.cc:" suffix rule, + and 'sub/Makefile.am' contained a ".ext.c:" suffix rule, automake + would have mistakenly placed into 'Makefile.in' rules to compile + "*.c" files into object files, and into 'sub/Makefile.in' rules to + compile "*.cc" files into object files --- rather than the other + way around. This is now fixed. + +* Testsuite work: + + - The test cases no longer have the executable bit set. This should + make it clear that they are not meant to be run directly; as + explained in t/README, they can only be run through the custom + 'runtest' script, or by a "make check" invocation. + + - The testsuite has seen the introduction of a new helper function + 'run_make', and several related changes. These serve a two-fold + purpose: + + 1. Remove brittleness due to the use of "make -e" in test cases. + + 2. Seamlessly allow the use of parallel make ("make -j...") in the + test cases, even where redirection of make output is involved + (see automake bug#11413 for a description of the subtle issues + in this area). + + - Several spurious failures have been fixed (they hit especially + MinGW/MSYS builds). See automake bugs #14493, #14494, #14495, + #14498, #14499, #14500, #14501, #14517 and #14528. + + - Some other minor miscellaneous changes and fixlets. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New in 1.13.2: + +* Documentation fixes: + + - The long-deprecated but still supported two-arguments invocation form + of AM_INIT_AUTOMAKE is documented once again. This seems the sanest + thing to do, given that support for such usage might need to remain + in place for an unspecified amount of time in order to cater to people + who want to define the version number for their package dynamically at + configure runtime (unfortunately, Autoconf does not yet support this + scenario, so we cannot delegate the work to it). + + - The serial testsuite harness is no longer reported as "deprecated", + but as "discouraged". We have no plan to remove it, nor to make its + use cause runtime warnings. + + - The parallel testsuite is no longer reported as "experimental"; it + is well tested, and should be stable now. + + - The 'shar' and 'tarZ' distribution formats and the 'dist-shar' and + 'dist-tarZ' options are obsolescent, and their use is deprecated + in the documentation. + + - Other minor miscellaneous fixes and improvements; in particular, + some improvements in cross-references. + +* Obsolescent features: + + - Use of suffix-less info files (that can be specified through the + '@setfilename' macro in Texinfo input files) is discouraged, and + its use will raise warnings in the 'obsolete' category. Simply + use the '.info' extension for all your info files, transforming + usages like: + + @setfilename myprogram + + into: + + @setfilename myprogram.info + + - Use of Texinfo input files with '.txi' or '.texinfo' extensions + is discouraged, and its use will raise warnings in the 'obsolete' + category. You are advised to simply use the '.texi' extension + instead. + +* Bugs fixed: + + - When the 'ustar' option is used, the generated configure script no + longer risks hanging during the tests for the availability of the + 'pax' utility, even if the user running configure has a UID or GID + that requires more than 21 bits to be represented. + See automake bug#8343 and bug#13588. + + - The obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC work once + again, as they did in Automake 1.12.x (albeit printing runtime + warnings in the 'obsolete' category). Removing them has turned + out to be a very bad idea, because it complicated distro packing + enormously. Making them issue fatal warnings, as we did in + Automake 1.13, has turned out to be a similarly very bad idea, + for exactly the same reason. + + - aclocal will no longer error out if the first local m4 directory + (as specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or + 'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it will merely report + a warning in the 'unsupported' category. This is done to support + some pre-existing real-world usages. See automake bug#13514. + + - aclocal will no longer consider directories for extra m4 files more + than once, even if they are specified multiple times. This ensures + packages that specify both + + AC_CONFIG_MACRO_DIR([m4]) in configure.ac + ACLOCAL_AMFLAGS = -I m4 in Makefile.am + + will work correctly, even when the 'm4' directory contains no + package-specific files, but is used only to install third-party + m4 files (as can happen with e.g., "libtoolize --install"). + See automake bug#13514. + + - Analysis of make flags in Automake-generated rules has been made more + robust, and more future-proof. For example, in presence of make that + (like '-I') take an argument, the characters in said argument will no + longer be spuriously considered as a set of additional make options. + In particular, automake-generated rules will no longer spuriously + believe to be running in dry mode ("make -n") if run with an invocation + like "make -I noob"; nor will they believe to be running in keep-going + mode ("make -k") if run with an invocation like "make -I kool" + (automake bug#12554). + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New in 1.13.1: * Bugs fixed: @@ -1467,8 +1785,8 @@ New in 1.9: tar-pax. The new option filename-length-max=99 helps diagnosing filenames that are too long for tar-v7. (PR/414) - - Variables aumented with `+=' are now automatically flattened (i.e., - trailing backslashes removed) and then wrapped around 80 colummns + - Variables augmented with `+=' are now automatically flattened (i.e., + trailing backslashes removed) and then wrapped around 80 columns (adding trailing backslashes). In previous versions, a long series of VAR += value1 @@ -2488,7 +2806,7 @@ New in 0.20: ----- -Copyright (C) 1995-2012 Free Software Foundation, Inc. +Copyright (C) 1995-2013 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