Re: GNU Automake 1.16 released

[Mathieu Lirzin]

Hello,

Eric Dorland  writes:

> Can this release be tagged in the git repository?
>
> * Mathieu Lirzin (m...@gnu.org) wrote:
>> We are pleased to announce the GNU Automake 1.16 minor release.

Done.

Thanks for the reminder.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: GNU Automake 1.16 released

[Eric Dorland]

Can this release be tagged in the git repository?

* Mathieu Lirzin (m...@gnu.org) wrote:
> We are pleased to announce the GNU Automake 1.16 minor release.
> 
> This release follows 1.15.1 which was made 8 months ago.
> 
> See below for the detailed list of changes since the
> previous version, as summarized by the NEWS file.
> 
> Download here:
> 
>   https://ftp.gnu.org/gnu/automake/automake-1.16.tar.gz
>   https://ftp.gnu.org/gnu/automake/automake-1.16.tar.xz
> 
> Please report bugs and problems to ,
> and send general comments and feedback to .
> 
> Thanks to everyone who has reported problems, contributed
> patches, and helped testing Automake!
> 
> -*-*-*-
> 
> * 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).
> This behavior of 'rm' is very widespread in the wild, and it will be
> required in the next POSIX version:
> 
>   
> 
> Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
> that the default 'rm' program in PATH satisfies this requirement,
> aborting the configure process if this is not the case.  For the
> moment, it's still possible to force the configuration process to
> succeed even with a broken 'rm', that that will no longer be the case
> for Automake 2.0.
> 
>   - 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: it will raise warnings in the "obsolete" category (but
> still no hard error of course, for compatibilities with the many, many
> packages that still relies on that variable).  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 retired
> 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 2.0.  There still is no
> certainty about this though: we'd first like to wait and see
> whether future Autoconf versions will be enhanced to guarantee
> that such a shell is always found and provided by the checks in
> ./configure.
> 
>   - 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.16:
> 
> * Miscellaneous changes
> 
>   - When subdir-objects is in effect, Automake will now construct
> shorter object file names when no programs and libraries name
> clashes are encountered.  This should make the discouraged use of
> 'foo_SHORTNAME' unnecessary in many cases.
> 
> * Bugs fixed:
> 
>   - Automatic dependency tracking has been fixed to work also when the
> 'subdir-object' option is used and some 'foo_SOURCES' definition
> contains unexpanded references to make variables, as in, e.g.:
> 
> a_src = sources/libs/aaa
> b_src = sources/bbb
> foo_SOURCES = $(a_src)/bar.c $(b_src)/baz.c
> 
> With such a setup, the created makefile fragment containing dependency
> tracking information will be correctly placed under the directories
> named 'sources/libs/aaa/.d