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

[Paolo Bonzini]

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

No, the porting hacks allow *building* with Autoconf 2.60.  This patch
is just to stop using now-deprecated interfaces.  Where it touches
libtool.m4, it keeps it backwards-compatible down to 2.58 as it is now.

> 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])

Ok.

> 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

Yes, because future upstream changes would also depend on
reimplementation/elimination of _AS_PREPARE.

> 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

Yes, I'm locking down the API though not the implementation.

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

I can change to lt_* variables.

>> +_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. ;)

:-)

> I just checked that as far back as autoconf 2.59, AS_INIT was still doing 
> AS_SHELL_SANITIZE.  However, AS_SHELL_SANITIZE 
> didn't unset CDPATH until 2.60; 

Yes, but libtool unsets CDPATH on its own.

> gcc has a good example of a 
> portability package for a number of newer autoconf features ported to an 
> older 
> autoconf environment).

Ralf and I wrote it. :-)

Paolo