GNU Automake 1.15.1 released

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GNU Automake 1.15.1 released

Mathieu Lirzin
We are pleased to announce the GNU Automake 1.15.1 maintenance release.

This much-needed, bug-fixing release comes after a year and a half of
stalling and inactivity in the Automake development.  The main
motivation for this release is to remove some warnings that were
appearing due to the deprecation of features in Perl and gzip latest
versions.

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

Download here:

  ftp://ftp.gnu.org/gnu/automake/automake-1.15.1.tar.gz
  ftp://ftp.gnu.org/gnu/automake/automake-1.15.1.tar.xz

Please report bugs and problems to <[hidden email]>,
and send general comments and feedback to <[hidden email]>.

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:

      <http://austingroupbugs.net/view.php?id=542>

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

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

* Bugs fixed:

  - The code has been adapted to remove a warning present since Perl
    5.22 stating that "Unescaped left brace in regex is deprecated".
    This warning has become an hard error in Perl 5.26 (bug#22372).

  - The generated Makefiles do not rely on the obsolescent GZIP
    environment variable which was used for passing arguments to
    'gzip'.  Compatibility with old versions has been
    preserved. (bug#20132)

* Miscellaneous changes:

  - Support the Windows version of the Intel C Compiler (icl) in the
    'compile' script in the same way the (compatible) Microsoft C
    Compiler is supported.

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

signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GNU Automake 1.15.1 released

Werner LEMBERG

> We are pleased to announce the GNU Automake 1.15.1 maintenance
> release.

Thanks a lot for your efforts!

Note that you forgot to tag the new release in the git repository, so
please do that :-)


    Werner

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GNU Automake 1.15.1 released

Mathieu Lirzin
Werner LEMBERG <[hidden email]> writes:

>> We are pleased to announce the GNU Automake 1.15.1 maintenance
>> release.
>
> Thanks a lot for your efforts!
>
> Note that you forgot to tag the new release in the git repository, so
> please do that :-)

I have just added the release tag to the repository.

Thank you for reporting this.  :)

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GNU Automake 1.15.1 released

Warren Young
In reply to this post by Mathieu Lirzin
On Jun 19, 2017, at 2:50 PM, Mathieu Lirzin <[hidden email]> wrote:
>
>  - 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.

Please clarify: does this apply to the shell script code written in *.m4 files included in the output configure script or to shell script code written in the user’s configure.ac file?

Currently, it’s the end user’s look-out if they do this.  What I’m suggesting is that it is possible for Autoconf to bend over backwards to ensure that the generated configure script runs under a local POSIX shell, if available, thereby making possible use of POSIX shell features in end-user macros and such even on systems where /bin/sh is not a POSIX shell.

As I understand it, the main difficulty here is that the generated configure script can’t start with anything other than #!/bin/sh for portability.  My suggestion is that one of the first things the generated code do is test whether it is running under a POSIX shell, and if not, try to find one and re-exec itself under that shell instead.

It’s generally possible to find a POSIX-compatible shell somewhere on the system these days if you only look hard enough: /usr/xpg4/bin/sh on old Solaris, /bin/bash on Linuxes where /bin/sh is pre-POSIX, /usr/bin/ksh on some SVR4 systems, etc.

Even the shells built into Busybox are fairly POSIX-compliant these days.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GNU Automake 1.15.1 released

Michael Felt
FYI: On AIX I tried using
export SHELL=/usr/bin/ksh93

and also running from /usr/bin/ksh93

ksh93 was never tested. Continued to complain that /usr/bin/ksh is not
POSIX (enough)

However, the test done in ./configure (somewhat simplified here) will
pass if ksh93 is used as the shell!

am_sh=/usr/bin/ksh93
    if { $am_sh -c "$am_bourne_compatible
(set -x; P=1 true 2>&3) 3>&1 2>/dev/null | grep P=1
  fail=0 && foo() { trap 'fail=1' 0; } && foo && test \$fail = 0
 test \$? -eq 0 || exit 1
 # Use 77 to indicate success (rather than 0), in case some shell
 # acts like Solaris 10's /bin/sh, exiting successfully on some
 # syntax errors.
 exit 77" 2>&1; test $? -eq 77; }
 then
 print 77
 else
 print not 77
fi

The result is "77" for ksh93 (and "not 77" for ksh)

On Tue, Jun 20, 2017 at 7:31 PM, Warren Young <[hidden email]> wrote:

> On Jun 19, 2017, at 2:50 PM, Mathieu Lirzin <[hidden email]> wrote:
>>
>>  - 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.
>
> Please clarify: does this apply to the shell script code written in *.m4 files included in the output configure script or to shell script code written in the user’s configure.ac file?
>
> Currently, it’s the end user’s look-out if they do this.  What I’m suggesting is that it is possible for Autoconf to bend over backwards to ensure that the generated configure script runs under a local POSIX shell, if available, thereby making possible use of POSIX shell features in end-user macros and such even on systems where /bin/sh is not a POSIX shell.
>
> As I understand it, the main difficulty here is that the generated configure script can’t start with anything other than #!/bin/sh for portability.  My suggestion is that one of the first things the generated code do is test whether it is running under a POSIX shell, and if not, try to find one and re-exec itself under that shell instead.
>
> It’s generally possible to find a POSIX-compatible shell somewhere on the system these days if you only look hard enough: /usr/xpg4/bin/sh on old Solaris, /bin/bash on Linuxes where /bin/sh is pre-POSIX, /usr/bin/ksh on some SVR4 systems, etc.
>
> Even the shells built into Busybox are fairly POSIX-compliant these days.

Loading...