Re: Strange LT_INIT behavior

[Peter O'Gorman]

Peter O'Gorman wrote:
> 
> On May 18, 2009, at 7:56 PM, Jeff Squyres wrote:
>>
>> Nifty idea!
>>
>> Unfortunately, it runs into a bit of a snag -- AC_PROG_F77 first
>> checks for g77; we have long-since overridden this ordering with our own:
>>

Ok, so what is happening, I think, is this. We have
AC_PROVIDE_IFELSE([AC_PROG_F77],
  [LT_LANG(F77)],
  [m4_define([AC_PROG_F77], defn([AC_PROG_F77])[LT_LANG(F77)])])

So, if AC_PROG_F77 has already appeared, it just puts LT_LANG(F77) into
configure, if not, it changes the definition of AC_PROG_F77 so that
LT_LANG(F77) comes after it. LT_LANG(F77) eventually becomes
_LT_LANG_F77_CONFIG.

Now, because AC_PROG_F77 (and its ilk) return things like the empty
string, or in the case of AC_PROG_CXX which returns "g++", when there is
no compiler, we have:

m4_defun([_LT_PROG_F77],
[
pushdef([AC_MSG_ERROR], [_lt_disable_F77=yes])
AC_PROG_F77
if test -z "$F77" || test "X$F77" = "Xno"; then
  _lt_disable_F77=yes
fi
popdef([AC_MSG_ERROR])
])# _LT_PROG_F77

And the first thing at the top of _LT_LANG_F77_CONFIG is
AC_REQUIRE([_LT_PROG_F77]), what this means is that in the case where
there is LT_INIT followed by AC_PROG_F77, we get

LT_INIT
...
_LT_PROG_F77
AC_PROG_F77(ARGS)
_LT_LANG_F77_CONFIG

So, AC_PROG_F77 gets output twice, the second time is the one the user
put into configure.ac which may have arguments, the first one is from
_LT_PROG_F77 and has no arguments. The second is pretty much ignored as
the cache vars etc are all set.

In the case where AC_PROG_F77 comes before LT_INIT, the f77 compiler
checks still happen twice, but at least the user's one with its
arguments happens first.

As far as I can tell, the AC_REQUIRE is unnecessary, in the case where
AC_PROG_F77 comes before LT_INIT, the compiler has already been tested
before we get to _LT_LANG_F77_CONFIG (this is guaranteed by the
AC_PROVIDE_IFLESE) in the other case, the compiler check is also
guaranteed because we have redefined AC_PROG_F77 so that it has both the
compiler check and _LT_LANG_F77_CONFIG.

I think this patch is correct, it removes the extra compiler check. But
I am not 100% sure, this code has been there for several years, I would
appreciate someone having a good look at it.

Also, I have no idea what to do when removing macros from libtool.m4, do
I need to do something with lt~obsolete.m4?

Thanks,
Peter
-- 
Peter O'Gorman
http://pogma.com

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 8af17a8..74610d6 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -5279,37 +5279,21 @@ CC="$lt_save_CC"
 ])# _LT_LANG_C_CONFIG
 
 
-# _LT_PROG_CXX
-# ------------
-# Since AC_PROG_CXX is broken, in that it returns g++ if there is no c++
-# compiler, we have our own version here.
-m4_defun([_LT_PROG_CXX],
-[
-pushdef([AC_MSG_ERROR], [_lt_caught_CXX_error=yes])
-AC_PROG_CXX
-if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
-    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
-    (test "X$CXX" != "Xg++"))) ; then
-  AC_PROG_CXXCPP
-else
-  _lt_caught_CXX_error=yes
-fi
-popdef([AC_MSG_ERROR])
-])# _LT_PROG_CXX
-
-dnl aclocal-1.4 backwards compatibility:
-dnl AC_DEFUN([_LT_PROG_CXX], [])
-
-
 # _LT_LANG_CXX_CONFIG([TAG])
 # --------------------------
 # Ensure that the configuration variables for a C++ compiler are suitably
 # defined.  These variables are subsequently used by _LT_CONFIG to write
 # the compiler configuration to `libtool'.
 m4_defun([_LT_LANG_CXX_CONFIG],
-[AC_REQUIRE([_LT_PROG_CXX])dnl
-m4_require([_LT_FILEUTILS_DEFAULTS])dnl
+[m4_require([_LT_FILEUTILS_DEFAULTS])dnl
 m4_require([_LT_DECL_EGREP])dnl
+if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
+    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
+    (test "X$CXX" != "Xg++"))) ; then
+  AC_PROG_CXXCPP
+else
+  _lt_caught_CXX_error=yes
+fi
 
 AC_LANG_PUSH(C++)
 _LT_TAGVAR(archive_cmds_need_lc, $1)=no
@@ -6532,32 +6516,16 @@ _LT_TAGDECL([], [compiler_lib_search_path], [1],
 ])# _LT_SYS_HIDDEN_LIBDEPS
 
 
-# _LT_PROG_F77
-# ------------
-# Since AC_PROG_F77 is broken, in that it returns the empty string
-# if there is no fortran compiler, we have our own version here.
-m4_defun([_LT_PROG_F77],
-[
-pushdef([AC_MSG_ERROR], [_lt_disable_F77=yes])
-AC_PROG_F77
-if test -z "$F77" || test "X$F77" = "Xno"; then
-  _lt_disable_F77=yes
-fi
-popdef([AC_MSG_ERROR])
-])# _LT_PROG_F77
-
-dnl aclocal-1.4 backwards compatibility:
-dnl AC_DEFUN([_LT_PROG_F77], [])
-
-
 # _LT_LANG_F77_CONFIG([TAG])
 # --------------------------
 # Ensure that the configuration variables for a Fortran 77 compiler are
 # suitably defined.  These variables are subsequently used by _LT_CONFIG
 # to write the compiler configuration to `libtool'.
 m4_defun([_LT_LANG_F77_CONFIG],
-[AC_REQUIRE([_LT_PROG_F77])dnl
-AC_LANG_PUSH(Fortran 77)
+[AC_LANG_PUSH(Fortran 77)
+if test -z "$F77" || test "X$F77" = "Xno"; then
+  _lt_disable_F77=yes
+fi
 
 _LT_TAGVAR(archive_cmds_need_lc, $1)=no
 _LT_TAGVAR(allow_undefined_flag, $1)=
@@ -6676,21 +6644,6 @@ fi # test "$_lt_disable_F77" != yes
 AC_LANG_POP
 ])# _LT_LANG_F77_CONFIG
 
-
-# _LT_PROG_FC
-# -----------
-# Since AC_PROG_FC is broken, in that it returns the empty string
-# if there is no fortran compiler, we have our own version here.
-m4_defun([_LT_PROG_FC],
-[
-pushdef([AC_MSG_ERROR], [_lt_disable_FC=yes])
-AC_PROG_FC
-if test -z "$FC" || test "X$FC" = "Xno"; then
-  _lt_disable_FC=yes
-fi
-popdef([AC_MSG_ERROR])
-])# _LT_PROG_FC
-
 dnl aclocal-1.4 backwards compatibility:
 dnl AC_DEFUN([_LT_PROG_FC], [])
 
@@ -6701,8 +6654,11 @@ dnl AC_DEFUN([_LT_PROG_FC], [])
 # suitably defined.  These variables are subsequently used by _LT_CONFIG
 # to write the compiler configuration to `libtool'.
 m4_defun([_LT_LANG_FC_CONFIG],
-[AC_REQUIRE([_LT_PROG_FC])dnl
-AC_LANG_PUSH(Fortran)
+[AC_LANG_PUSH(Fortran)
+
+if test -z "$FC" || test "X$FC" = "Xno"; then
+  _lt_disable_FC=yes
+fi
 
 _LT_TAGVAR(archive_cmds_need_lc, $1)=no
 _LT_TAGVAR(allow_undefined_flag, $1)=