Re: LT_AC_PROG_SED

[Gary V. Vaughan]

Ralf Wildenhues wrote:
> Hi Gary,

Hallo Ralf!

I'm attaching the revised branch-1-5 version of the patch for approval.
More inline...

> > Ralf Wildenhues wrote:
> >
> > > * Gary V. Vaughan wrote on Fri, Feb 10, 2006 at 11:52:04AM CET:
> > 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.

Agreed.  This is worth documenting in HACKING IMHO.

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

Attached tested with released and bleeding edge autotools.

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

Thanks for the review.  I'll commit presently.

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://blog.azazil.net
GNU Hacker           / )=   http://trac.azazil.net/projects/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook