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
