Re: LT_AC_PROG_SED

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Wed, May 17, 2006 at 03:21:48PM CEST:
> 
> Sorry for the long delay.

Don't worry.  My latency has been just as long; the backlog is still
large, and it will take a while for me to wade through it...

> Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Fri, Feb 10, 2006 at 11:52:04AM CET:
> >> Okay to commit?
> >
> >Comments inline.  Please note my comments are completely untested,
> >so please take them with a grain of salt.
> 
> ACK.  I think these patches are still worth applying, but for the small
> changes described below.  Any objections?

Comments below.

> >>+# Old name:
> >>+AU_ALIAS([LT_AC_PROG_SED], [AC_PROG_SED])
> >>+dnl aclocal-1.4 backwards compatibility:
> >>+dnl AC_DEFUN([LT_AC_PROG_SED], [])
> >>+
> >
> >With old aclocal, this will pull in libtool.m4 for users of
> >LT_AC_PROG_SED.
> 
> Yes, and they'll need it to get that LT_AC_PROG_SED expanded correctly!

Right.  Dummy me.

> >That may actually be ok for them, but it won't do what you want:
> >forward compatiblity plus automatic independence of libtool.m4
> >without user changes, as soon as autoconf-2.60 is out.  Right?
> >
> >Ah, maybe you rather want users to switch to AC_PROG_SED, but
> >help them with the autoupdate note?
> 
> Yes.  LT_AC_PROG_SED was never documented, although unfortunately
> is in use nevertheless.  If they don't autoupdate, the AU_ALIAS
> will get them autoconf's AC_PROG_SED if autoconf is new enough or else
> our m4_defun replacement.  If they are already using AC_PROG_SED
> (presumably from autoconf), even old aclocal won't pull in libtool.m4
> just for LT_AC_PROG_SED.
> 
> There is still the problem with pulling in an old installed libtool.m4
> with an `AC_DEFUN([LT_AC_PROG_SED], [' declaration... but we don't
> address that problem in branch-1-5 for any other macros at the moment
> either.

Aahh.  That's why you can't change the branch-1-5 version from
  AC_DEFUN([LT_AC_PROG_SED], ...)

to
  m4_defun([LT_AC_PROG_SED], ...)

now: if the user has 1.5.24's libtool.m4 and 1.5.22's libtool.m4 both in
aclocal's search path, both will be pulled in.  Yuck.

General rule: within the branch-1-5 branch, you cannot ever remove an
AC_DEFUNed name.  Not. ever.

> >>
> >>+# Old name:
> >>+AU_ALIAS([LT_AC_PROG_SED], [AC_PROG_SED])
> >
> >Is it allowed to AU_ALIAS a macro that is not AC_DEFUN'ed?
> >(I just changed AC_PROG_SED to be m4_defun'ed, not AC_DEFUN'ed).
> 
> I can't find any reason why not.  Both autoupdate and autoconf do
> the right thing here (I didn't test with ancient autotools though).

OK.

> >>+dnl aclocal-1.4 backwards compatibility:
> >>+dnl AC_DEFUN([LT_AC_PROG_SED], [])
> >
> >With old aclocal, this will pull in libtool.m4 for users of
> >LT_AC_PROG_SED.
> 
> See above.

OK.

> >>Index: libtool-HEAD/libltdl/m4/lt~obsolete.m4
> >>===================================================================
> >>--- libtool-HEAD.orig/libltdl/m4/lt~obsolete.m4
> >>+++ libtool-HEAD/libltdl/m4/lt~obsolete.m4
> >>@@ -58,7 +58,6 @@ m4_ifndef([AC_LIBTOOL_PROG_COMPILER_PIC]
> >>m4_ifndef([AC_LIBTOOL_PROG_LD_SHLIBS], 
> >>[AU_DEFUN([AC_LIBTOOL_PROG_LD_SHLIBS])])
> >>m4_ifndef([AC_LIBTOOL_POSTDEP_PREDEP], 
> >>[AU_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP])])
> >>m4_ifndef([LT_AC_PROG_EGREP],        [AU_DEFUN([LT_AC_PROG_EGREP])])
> >>-m4_ifndef([LT_AC_PROG_SED],                [AU_DEFUN([LT_AC_PROG_SED])])
> >
> >
> >Doing this will pull in an older also-installed libtool.m4: some
> >aclocal versions will not fall for the 1.4 hack above but still won't
> >see the AU_ALIAS.  Actually, AU_ALIAS isn't matched before 1.9.5.
> 
> Good point.  The lt~obsolete.m4 part of the patch is wrong, I don't want
> to apply that part now.

Fine.  You can add the AC_SUBST to branch-1-5, but you cannot AU_ALIAS
there, and you cannot AC_DEFUN([AC_PROG_SED]) there.  So IMHO best to
leave branch-1-5 as is otherwise.  Iff you want to add AC_PROG_SED, then
probably best to
  m4_defun([AC_PROG_SED], ...)
  AC_DEFUN([LT_AC_PROG_SED],
  [AC_DIAGNOSE([obsolete], [...])dnl
  AC_PROG_SED])
  
so that you avoid the backward compatibility traps of both an AU_DEFUNed
or AU_ALIASed LT_AC_PROG_SED (untested BTW).

The HEAD patch is fine without the lt~obsolete change and with
LT_AC_PROG_SED.

Cheers,
Ralf