Re: [PATCH 3/6] use documented m4sh interfaces

[Eric Blake]

Paolo Bonzini <bonzini <at> gnu.org> writes:

> 
> Here we start with the meat.  This patch ends Libtool's indiscriminate
> usage of undocumented (and in some cases deprecated) M4sh interfaces.
> 
> AS_SHELL_SANITIZE is replaced with either AS_INIT or AS_INIT_GENERATED
> (the latter also subsumes _AS_PREPARE), and the standard M4sh diversions
> are used.  AS_INIT_GENERATED is a new macro in Autoconf's latest git,
> whose source we include in libtool.m4 if needed.  (Actually we copy it
> to _LT_INIT_GENERATED, with some hacks, to avoid problems with aclocal
> pull libtool.m4 into every file).

I know you mentioned (in 7/6) that you can turn on enough porting hacks to 
allow running with Autoconf 2.60; does that include this patch?

>  PROGRAM=clcommit
> 
> -AS_SHELL_SANITIZE
> -$as_unset CDPATH
> -
> +m4_divert_pop

When possible, it's nicer to use the 1-argument m4_divert_pop, as a sanity 
check that no macro changed the active diversion (with m4_divert or otherwise) 
in the meantime.  For this instance, this should be:

m4_divert_pop([HEADER-COPYRIGHT])

> +++ b/libltdl/m4/libtool.m4
> @@ -553,6 +553,34 @@ esac
>  _LT_OUTPUT_LIBTOOL_INIT
>  ])
> 
> +# AS_INIT_GENERATED(FILE, [COMMENT])

s/AS/_LT/

I still have some pending ideas for AS_INIT_GENERATED (such as bumping the 
value of _m4_divert(BODY) and adding an m4_wrap hook that can then minimize the 
preface of generated files to m4sh features actually used, rather than dumping 
all of _AS_PREPARE in every child script); I guess we have to decide if your 
current fallback implementation of _LT_INIT_GENERATED it is mature enough to 
use even if AS_INIT_GENERATED changes in the future, or whether you plan to 
track future upstream changes.  Or put another way, by using this interface, 
you are now locking down the API that we must publish for AS_INIT_GENERATED in 
the next autoconf release; so hopefully we are happy that it is a sufficient 
interface (and that all future tweaks on the m4sh side of things will only be 
optimizations, rather than interface changes).  At any rate, since 2.64 (or 
should it be autoconf 3.0?) isn't released yet, would it be worth adding a 
comment mentioning which commit you borrowed the fallback from?

> +[m4_defun([_LT_INIT_GENERATED],
> +[m4_require([AS_PREPARE])]dnl
> +[m4_pushdef([AS_MESSAGE_LOG_FD])]dnl
> +[as_write_fail=0

I guess we are safe invading the m4sh namespace in our fallback, if only 
because we know that all supported versions of autoconf that lack 
AS_INIT_GENERATED did not use as_write_fail.

> +_LT_INIT_GENERATED(["$CONFIG_LT"],
> +[# Run this file to recreate a libtool stub with the current configuration.])

I knew I made the right decision by adding that optional comment argument. ;)

> +AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])dnl
... 
> -AS_SHELL_SANITIZE
> -$as_unset CDPATH

I just checked that as far back as autoconf 2.59, AS_INIT was still doing 
AS_SHELL_SANITIZE.  For now, 2.59 is the current PREREQ in configure.ac, 
although libtool.m4 claims it can get by with 2.58.  However, AS_SHELL_SANITIZE 
didn't unset CDPATH until 2.60; that argues that we should either add a 
AC_PREREQ([2.60]) (for just configure.ac while bootstrapping libtool? or for 
libtool.m4?), or else provide a fallback and continue to unset CDPATH manually 
(perhaps after doing an m4_version_compare; gcc has a good example of a 
portability package for a number of newer autoconf features ported to an older 
autoconf environment).

> +++ b/tests/testsuite.at
> @@ -23,6 +23,8 @@
>  # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
>  ####
> 
> +AT_INIT
> +
>  m4_divert_push([PREPARE_TESTS])dnl
>  : ${tst_dist=dist}
>  : ${ACLOCAL=aclocal}
> @@ -369,5 +371,4 @@ dnl AT_TESTED([grep autoreconf autom4te automake])
>  ## The suite.  ##
>  ## ----------- ##
> 
> -AT_INIT
> -# The other tests will be appended here by the Makefile rule.
> +# Tests will be appended here by the Makefile rule.

This move seems a bit unrelated to the others and a bit more cosmetic in 
nature, but I guess it's okay as part of this patch.

-- 
Eric Blake