Ralf Wildenhues wrote:
Hi Gary,
Hi Ralf!
Sorry for the long delay.
* 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?
Index: ChangeLog
from Gary V. Vaughan <[EMAIL PROTECTED]>
* libtool.m4 (LT_AC_PROG_SED): Rename to AC_PROG_SED and only define
if autoconf failed to provide a definition. AC_SUBST([SED]) for
compatibility with future autoconf release of AC_PROG_SED. Provide
an autoupdate alias to LT_AC_PROG_SED for projects that used this
undocumented macro.
Index: libtool-1-5/libtool.m4
===================================================================
--- libtool-1-5.orig/libtool.m4
+++ libtool-1-5/libtool.m4
@@ -5987,17 +5987,15 @@ AC_DEFUN([LT_AC_PROG_RC],
[AC_CHECK_TOOL(RC, windres, no)
])
+m4_ifndef([AC_PROG_SED], [
############################################################
# NOTE: This macro has been submitted for inclusion into #
# GNU Autoconf as AC_PROG_SED. When it is available in #
# a released version of Autoconf we should remove this #
# macro and use it instead. #
############################################################
-# LT_AC_PROG_SED
-# --------------
-# Check for a fully-functional sed program, that truncates
-# as few characters as possible. Prefer GNU sed if found.
-AC_DEFUN([LT_AC_PROG_SED],
+
+AC_DEFUN([AC_PROG_SED],
With old aclocal, this will pull in libtool.m4 for users of AC_PROG_SED.
This is definitely not ok.
The offending line should, of course, read: `m4_defun([AC_PROG_SED], ['
[AC_MSG_CHECKING([for a sed that does not truncate output])
AC_CACHE_VAL(lt_cv_path_SED,
[# Loop through the user's path and test for sed and gsed.
@@ -6047,5 +6045,13 @@ for lt_ac_sed in $lt_ac_sed_list /usr/xp
done
])
SED=$lt_cv_path_SED
+AC_SUBST([SED])
AC_MSG_RESULT([$SED])
-])
+])#AC_PROG_SED
+])#m4_ifndef
+
+# 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!
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.
Index: ChangeLog
from Gary V. Vaughan <[EMAIL PROTECTED]>
* libltdl/m4/lt~obsolete (LT_AC_PROG_SED): Removed in favour
of...
* libltdl/m4/libtool.m4 (LT_AC_PROG_SED): Declarations for
compatibility with old versions of libtool, and old versions of
aclocal.
Index: libtool-HEAD/libltdl/m4/libtool.m4
===================================================================
--- libtool-HEAD.orig/libltdl/m4/libtool.m4
+++ libtool-HEAD/libltdl/m4/libtool.m4
@@ -6758,6 +6758,11 @@ AC_MSG_RESULT([$SED])
])#AC_PROG_SED
])#m4_ifndef
+# 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).
+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.
# _LT_CHECK_XSI_SHELL
# -------------------
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.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://blog.azazil.net
GNU Hacker / )= http://trac.azazil.net/projects/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
