[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LT_AC_PROG_SED
From: |
Gary V. Vaughan |
Subject: |
Re: LT_AC_PROG_SED |
Date: |
Wed, 17 May 2006 17:04:26 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20050317) |
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