Automake test release 1.13b (will become 1.14)

[Stefano Lattarini]

We are pleased to announce the GNU Automake 1.13b test release.

This release comes with two important changes:

  1. It introduces a new feature aimed at making the implementation
     of non-recursive built-in systems more convenient and manageable
     (thanks to the new support for the '%reldir%' and '%canon_reldir%'
     automake-time substitutions).

  2. It improves the handling of C compiles not supporting the conjunct
     use of the '-c' and '-o' option (unfortunately, this improvement
     comes with a couple of minor backward-incompatibilities, described
     in detail in the NEWS section below).  Among th other things, this
     means that you no longer need to explicitly call the AM_PROG_CC_C_O
     macro yourself in configure.ac (pre-existing invocation of this
     macro are of course still accepted correctly working, for the sake
     of backward-compatibility).

The 1.14 release also introduces new (non-fatal) runtime warnings to
simplify the transition to Automake 2.0.  You are free to ignore such
warnings for now, but should address them before the transition to
Automake 2.0 (whose ETA is about one year from now, so no need to
hurry too much).

See below for the detailed list of changes since the previous version,
as summarized by the NEWS file.

Download here:

  ftp://alpha.gnu.org/gnu/automake/automake-1.13b.tar.gz
  ftp://alpha.gnu.org/gnu/automake/automake-1.13b.tar.xz

Please report bugs and problems to <address@hidden>,
and send general comments and feedback to <address@hidden>.

Thanks to everyone who has reported problems, contributed
patches, and helped testing Automake!

-*-*-*-

NEWS entries for Automake 1.14 follows...

-*-*-*-

* 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 real backward incompatibility.

  - See discussion about automake bug#13578 for more details and
    background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>

* WARNING: Future backward-incompatibilities!

  - 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:
    <http://austingroupbugs.net/view.php?id=542>

  - 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 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 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:
    <http://www.sgi.com/services/support/irix_mips_support.html>

  - 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.

  - Automake-provided scripts and makefile recipes might (finally!)
    start assuming a POSIX shell in Automake 2.0.

  - 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-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:
    <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).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~