compile: use 'compile' script when "-c -o" is used with losing compilers
[platform/upstream/automake.git] / NEWS
diff --git a/NEWS b/NEWS
index e1fcd27..09bfc1e 100644 (file)
--- a/NEWS
+++ b/NEWS
-New in 1.12.6:
+New in 1.13.2:
 
 * WARNING: Future backward-incompatibilities!
 
-  - Future versions of Automake 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.
+  - Automake 1.14 will 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).
 
-  - Support for the "Cygnus-style" trees (as enabled by the 'cygnus'
-    option) will be removed in the next major Automake release (1.13).
+  - Automake 1.14 will drop support for the long-deprecated 'configure.in'
+    name for the Autoconf input file.  You are advised to start using
+    recommended name 'configure.ac' instead, ASAP.
 
   - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
-    be removed in Automake 1.13.  The $(mkdir_p) make variable and the
+    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.
+    $(MKDIR_P)) for the moment, for better backward compatibility; but
+    you are advised to stop using ASAP.
+
+  - The ACLOCAL_AMFLAGS special make variable will be fully deprecated
+    in Automake 1.14 (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 was introduced in
+    Automake 1.13).
+
+  - 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
+    <http://www.sgi.com/services/support/irix_mips_support.html> 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.
+
+  - Automake-provided scripts and makefile recipes might (finally!)
+    start assuming a POSIX shell in Automake 1.14.
+
+  - Starting from Automake 1.14, 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').
+
+* 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>
+
+  - 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.
+
+* 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.
+
+* 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 an usage might need to remain
+    in place for a unspecified amount of time in order to cater for 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).
+
+* 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.
 
-  - Autoconf 2.65 or later will be required by the next major Automake
-    version (1.13).  Until now, Automake has required Autoconf version
-    2.62 or later.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.1:
+
+* Bugs fixed:
+
+  - Use of the obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC now
+    causes a clear and helpful error message, instead of obscure ones
+    (issue introduced in Automake 1.13).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13:
+
+* Bugs fixed:
+
+  - ylwrap renames properly header guards in generated header files
+    (*.h), instead of leaving Y_TAB_H.
+
+  - ylwrap now also converts header guards in implementation files
+    (*.c).  Because ylwrap failed to rename properly #include in the
+    implementation files, current versions of Bison (e.g., 2.7)
+    duplicate the generated header file in the implementation file.
+    The header guard then protects the implementation file from
+    duplicate definitions from the header file.
+
+* Version requirements:
+
+  - Autoconf 2.65 or greater is now required.
+
+  - The rules to build PDF and DVI output from Texinfo input now
+    require Texinfo 4.9 or later.
+
+* Obsolete features:
 
-  - Starting from the next major Automake version (1.13), the rules
-    to build pdf, ps and dvi output from Texinfo input will use the
-    '--build-dir' option by default.  Since such an option was only
-    introduced in Texinfo 4.9, this means that Makefiles generated by
-    future Automake versions will require at least that version of
-    Texinfo.
+  - Support for the "Cygnus-style" trees (once enabled by the 'cygnus'
+    option) has been removed.  See discussion about automake bug#11034
+    for more background: <http://debbugs.gnu.org/11034>.
 
-  - Starting from the next major Automake version (1.13), the parallel
-    testsuite harness (previously only enabled by the 'parallel-tests'
-    option) will become the default one; the older serial testsuite
-    harness will still be available through the use of the 'serial-tests'
-    option.
+  - The deprecated aclocal option '--acdir' has been removed.  You
+    should use the options '--automake-acdir' and '--system-acdir'
+    instead (which have been introduced in Automake 1.11.2).
 
-  - The following long-obsolete m4 macros will be removed in the
-    next major Automake version (1.13):
+  - The following long-obsolete m4 macros have been removed:
 
       AM_PROG_CC_STDC:    superseded by AC_PROG_CC since October 2002
       fp_PROG_CC_STDC:    broken alias for AM_PROG_CC_STDC
@@ -46,27 +190,174 @@ New in 1.12.6:
                           of the now-removed automatic de-ANSI-fication
                           support of Automake)
 
-  - All the "old alias" macros in 'm4/obsolete.m4' will be removed in
-    the next major Automake version (1.13).
+  - All the "old alias" macros in 'm4/obsolete.m4' have been removed.
 
-  - The '--acdir' option of aclocal is deprecated, and will probably
-    be removed in the next major Automake release (1.13).  You should
-    use the options '--automake-acdir' and '--system-acdir' instead
-    (which have been introduced in Automake 1.11.2).
+  - Use of the long-deprecated two- and three-arguments invocation forms
+    of the AM_INIT_AUTOMAKE is no longer documented.  It's still supported
+    though (albeit with a warning in the 'obsolete' category), to cater
+    for people who want to define the version number for their package
+    dynamically (e.g., from the current VCS revision).  We'll have to
+    continue this support until Autoconf itself is fixed to allow better
+    support for such dynamic version numbers.
+
+* Elisp byte-compilation:
+
+  - The byte compilation of '.el' files into '.elc' files is now done
+    with a suffix rule.  This has simplified the compilation process, and
+    more importantly made it less brittle.  The downside is that emacs is
+    now invoked once for each '.el' files, which cause some noticeable
+    slowdowns.  These should however be mitigated on multicore machines
+    (which are becoming the norm today) if concurrent  make ("make -j")
+    is used.
+
+  - Elisp files placed in a subdirectory are now byte-compiled to '.elc'
+    files in the same subdirectory; for example, byte-compiling of file
+    'sub/foo.el' file will result in 'sub/foo.elc' rather than in
+    'foo.elc'.  This behaviour is backward-incompatible with older
+    Automake versions, but it is more natural and more sane.  See also
+    automake bug#7441.
+
+  - The Emacs invocation performing byte-compilation of '.el' files honors
+    the $(AM_ELCFLAGS) and $(ELCFLAGS) variables; as typical, the former
+    one is  developer-reserved and the latter one user-reserved.
+
+  - The 'elisp-comp' script, once provided by Automake, has been rendered
+    obsoleted by the just-described changes, and thus removed.
+
+* Changes to Automake-generated testsuite harnesses:
+
+  - The parallel testsuite harness (previously only enabled by the
+    'parallel-tests' option) is the default one; the older serial
+    testsuite harness will still be available through the use of the
+    'serial-tests' option (introduced in Automake 1.12).
+
+  - The 'color-tests' option is now unconditionally activated by default.
+    In particular, this means that testsuite output is now colorized by
+    default if the attached terminal seems to support ANSI escapes, and
+    that the user can force output colorization by setting the variable
+    AM_COLOR_TESTS to "always".  The 'color-tests' is still recognized
+    for backward-compatibility, although it's a handled as a no-op now.
+
+* Silent rules support:
 
-  - The 'missing' script will no longer try to update the timestamp
-    of out-of-date files that require a maintainer-specific tool to be
+  - Support for silent rules is now always active in Automake-generated
+    Makefiles.  So, although the verbose output is still the default,
+    the user can now always use "./configure --enable-silent-rules" or
+    "make V=0" to enable quieter output in the package he's building.
+
+  - The 'silent-rules' option has now become a no-op, preserved for
+    backward-compatibility only.  In particular, its use no longer
+    disables the warnings in the 'portability-recursive' category.
+
+* Texinfo Support:
+
+  - The rules to build PDF and DVI files from Texinfo input now require
+    Texinfo 4.9 or later.
+
+  - The rules to build PDF and DVI files from Texinfo input now use the
+    '--build-dir' option, to keep the auxiliary files used by texi2dvi
+    and texi2pdf around without cluttering the build directory, and to
+    make it possible to run the "dvi" and "pdf" recipes in parallel.
+
+* Automatic remake rules and 'missing' script:
+
+  - The 'missing' script no longer tries to update the timestamp of
+    out-of-date files that require a maintainer-specific tool to be
     remade, in case the user lacks such a tool (or has a too-old version
-    of it).  In fact, starting from Automake 1.13, all it'll do will be
-    giving more useful warnings than a bare "command not found" from a
-    make recipe would.
+    of it).  It just gives a useful warning, and in some cases also a
+    tip about how to obtain such a tool.
+
+  - The missing script has thus become useless as a (poor) way to work
+    around the sketched-timestamps issues that can happen for projects
+    that keep generated files committed in their VCS repository.  Such
+    projects are now encouraged to write a custom "fix-timestamps.sh"
+    script to avoid such issues; a simple example is provided in the
+    "CVS and generated files" chapter of the automake manual.
+
+* Recursive targets:
+
+  - The user can now define his own recursive targets that recurse
+    in the directories specified in $(SUBDIRS).  This can be done by
+    specifying the name of such targets in invocations of the new
+    'AM_EXTRA_RECURSIVE_TARGETS' m4 macro.
+
+* Tags:
+
+  - Any failure in the recipe of the "tags", "ctags", "cscope" or
+    "cscopelist" targets in a subdirectory is now propagated to the
+    top-level make invocation.
+
+  - Tags are correctly computed also for files in _SOURCES variables that
+    only list files with non-standard suffixes (see automake bug#12372).
+
+* Improvements to aclocal and related rebuilds rules:
+
+  - Autoconf-provided macros AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS
+    are now traced by aclocal, and can be used to declare the local m4
+    include directories.  Formerly, one had to specify it with an explicit
+    '-I' option to the 'aclocal' invocation.
+
+  - The special make variable ACLOCAL_AMFLAGS is deprecated; future
+    Automake versions will warn about its use, and later version will
+    remove support for it altogether.
+
+* The depcomp script:
+
+  - Dropped support for libtool 1.4.
+
+  - Various internal refactorings.  They should cause no visible change,
+    but the chance for regression is there anyway, so please report any
+    unexpected or suspicious behaviour.
+
+  - Support for pre-8.0 versions of the Intel C Compiler has been dropped.
+    This should cause no problem, since icc 8.0 has been released in
+    December 2003 -- almost nine years ago.
+
+  - Support for tcc (the Tiny C Compiler) has been improved, and is now
+    handled through a dedicated 'tcc' mode.
+
+* The ylwrap script:
+
+  - ylwrap generates header guards with a single '_' for series of non
+    alphabetic characters, instead of several.  This is what Bison >=
+    2.5.1 does.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Bugs fixed in 1.12.6:
 
-* Bugs introduced in 1.12.5:
+* Python-related bugs:
+
+  - The default installation location for python modules has been improved
+    for Python 3 on Debian and Ubuntu systems, changing from:
+
+        ${prefix}/lib/python3/dist-packages
+
+    to
+
+        ${prefix}/lib/python3.x/site-packages
 
-  - The maintainer rebuild rules for Makefiles and aclocal.m4 in Automake's
-    own build system works correctly again.
+    This change should ensure modules installed using the default ${prefix}
+    "/usr/local" are found by default by system python 3.x installations.
+    See automake bug#10227.
+
+  - Python byte-compilation supports the new layout mandated by PEP-3147,
+    with its __pycache__ directory (automake bug#8847).
+
+* Build system issues:
+
+  - The maintainer rebuild rules for Makefiles and aclocal.m4 in
+    Automake's own build system works correctly again (bug introduced
+    in Automake 1.12.5).
+
+* Testsuite issues:
+
+  - The Vala-related tests has been changed to adjust to the removal of
+    the 'posix' profile in the valac compiler.  See automake bug#12934
+    a.k.a. bug#12522.
+
+  - Some spurious testsuite failures related to older tools and systems
+    have been fixed.
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2285,7 +2576,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