Merge branch 'micro' into maint
[platform/upstream/automake.git] / NEWS
diff --git a/NEWS b/NEWS
index a6f0953..1cc00a4 100644 (file)
--- a/NEWS
+++ b/NEWS
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+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:
+    <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
+    <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
+
+  - 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:
+
+        <http://austingroupbugs.net/view.php?id=542>
+
+    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:
@@ -154,17 +276,6 @@ New in 1.13.3:
 
 New in 1.13.2:
 
-* 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.
-
-  - 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.
-
 * Documentation fixes:
 
   - The long-deprecated but still supported two-arguments invocation form
@@ -189,6 +300,25 @@ New in 1.13.2:
   - 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