[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LT_AC_PROG_SED
From: |
Ralf Wildenhues |
Subject: |
Re: LT_AC_PROG_SED |
Date: |
Wed, 17 May 2006 16:39:34 +0200 |
User-agent: |
Mutt/1.5.11 |
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