From: Stefano Lattarini Date: Wed, 20 Feb 2013 21:14:55 +0000 (+0100) Subject: Merge branch 'branch-1.13.2' into maint X-Git-Tag: v1.13b~88 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5daad7029bfc62932b84517b49c73b38bd5c750c;p=thirdparty%2Fautomake.git Merge branch 'branch-1.13.2' into maint * branch-1.13.2: coverage: expose automake bug#13760 tests: refactor/enhance tests about make dry-run mode maint: describe new versioning and branching scheme, and adjust to it Signed-off-by: Stefano Lattarini --- 5daad7029bfc62932b84517b49c73b38bd5c750c diff --cc HACKING index a4f89bd66,604bf676b..b52660089 --- a/HACKING +++ b/HACKING @@@ -96,9 -86,54 +96,51 @@@ default), and other portions using the GNU style (cperl-mode's default). Write new code using GNU style. -* Don't use & for function calls, unless required. +* Don't use & for function calls, unless really required. The use of & prevents prototypes from being checked. - Just as above, don't change massively all the code to strip the - &, just convert the old code as you work on it, and write new - code without. + ============================================================================ + = Automake versioning and compatibility scheme + + * There are three kinds of automake releases: + + - new major releases (e.g., 2.0, 5.0) + - new minor releases (e.g., 1.14, 2.1) + - micro a.k.a. "bug-fixing" releases (e.g., 1.13.2, 2.0.1, 3.5.17). + + A new major release should have the major version number bumped, and + the minor and micro version numbers reset to zero. A new minor release + should have the major version number unchanged, the minor version number + bumped, and the micro version number reset to zero. Finally, a new + micro version should have the major and minor version numbers unchanged, + and the micro version number bumped. + + For example, the first minor version after 1.13.2 will be 1.14; the + first bug-fixing version after 1.14 that will be 1.14.1; the first + new major version after all such releases will be 2.0; the first + bug-fixing version after 2.0 will be 2.0.1; and a further bug-fixing + version after 2.0.1 will be 2.0.2. + + * Micro releases should be just bug-fixing releases; no new features + should be added, and ideally, only trivial bugs, recent regressions, + or documentation issues should be addressed by them. + + * Minor releases can introduce new "safe" features, do non-trivial + but mostly safe code clean-ups, and even add new runtime warnings + (rigorously non-fatal); but they shouldn't include any backward + incompatible change, nor contain any potentially destabilizing + refactoring or sweeping change, nor introduce new features whose + implementation might be liable to cause bugs or regressions in + existing code. + + * Major releases can introduce backward-incompatibilities (albeit + such incompatibilities should be announced well in advance, and + a smooth transition plan prepared for them), and try more risking + and daring refactorings and code cleanups. + + * For more information, refer to the extensive discussion associated + with automake bug#13578. + ============================================================================ = Working with git diff --cc NEWS index 1c97e9ed9,1ea9fa638..fbd576106 --- a/NEWS +++ b/NEWS @@@ -39,66 -76,22 +76,70 @@@ 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.13.2: -* Obsolescent features: +* 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: + + + + - 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. This "rewrite" of + AC_PROG_CC is only meant to be temporary, since future Autoconf + versions should provide all the features Automake needs. + + - The AM_PROG_CC_C_O is no longer useful, and its use is a no-op + now. Future Automake versions might start warning that this + macro is obsolete. For better backward-compatibility, this macro + still sets a proper 'ac_cv_prog_cc_*_c_o' cache variable, and + define the 'NO_MINUS_C_MINUS_O' C preprocessor symbol, but you + should really stop relying on that. + +* 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 1.14. - - 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. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - 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. +New in 1.13.2: * Documentation fixes: