[SCM] GNU Libtool branch, master, updated. v2.4.2-276-g991b5e5

[Gary V. Vaughan]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Libtool".

The branch, master has been updated
       via  991b5e52a77c4705614387b370219b3a24e9dc1c (commit)
      from  a61a1114ae1464c39b54e88d1a30735c7daca4b2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 991b5e52a77c4705614387b370219b3a24e9dc1c
Author: Gary V. Vaughan <address@hidden>
Date:   Sat Oct 6 11:47:56 2012 +0700

    tests: allow for unstable fortran output ordering.
    
    Due to differences in line-endings between C stdout and Fortran
    stdout, as well as unpredictable output ordering between
    platforms and runtimes, weaken success criteria to not require
    the entire output of fortran programs to match a test case.
    * itests/fcdemo.at, tests/f77demo.at (_LT_CHECK_EXECUTE):
    Improve comments, and weaken test case to grep for a known line
    in the f77 runtime output.
    
    Signed-off-by: Gary V. Vaughan <address@hidden>

-----------------------------------------------------------------------

Summary of changes:
 tests/f77demo.at |   33 +++++++++++++++------------------
 tests/fcdemo.at  |   21 +++++++++++++++------
 2 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/tests/f77demo.at b/tests/f77demo.at
index 5978b3d..a06af37 100644
--- a/tests/f77demo.at
+++ b/tests/f77demo.at
@@ -245,10 +245,10 @@ LT_AT_AUTOHEADER
 m4_define([_LT_CHECK_EXECUTE],
 [LT_AT_MAKE
 
-# Oddly, the output of dynamically linked fprogram differs depending
-# on whether it is redirected to a file or sent to stdout, so we
-# just check return status, and ignore output.
-# Advice on this weirdness from a Fortran user much appreciated!
+# Due to differences in line-endings between C stdout and Fortran
+# stdout, as well as unpredictable output ordering between platforms
+# and runtimes, we can't reliably check the output here... although
+# it should be some variation of the following:
 LT_AT_HOST_DATA([expout],
 [[ Welcome to GNU libtool Fortran demo!
  Real programmers write in FORTRAN.
@@ -260,8 +260,13 @@ LT_AT_HOST_DATA([expout],
  fsub3 returned, saying that 4 *           2  =           8
  fsub3 is ok!
 ]])
-LT_AT_EXEC_CHECK([./fprogram], 0, [ignore])
+LT_AT_EXEC_CHECK([./fprogram], 0, [stdout])
 
+# A weaker output content check that is agnostic to the issues above.
+AT_CHECK([grep 'Welcome to GNU libtool Fortran demo!' stdout],
+         [0], [ignore])
+
+# Similarly, we can't reliably compare actual output with the following.
 LT_AT_HOST_DATA([expout],
 [[Welcome to GNU libtool mixed C/Fortran demo!
 The C subroutine returned, claiming that 2*2 = 4
@@ -276,7 +281,11 @@ The C wrapper to the fortran subroutine returned,
 claiming that 2*2 = 4
 The Fortran 77 subroutine is ok!
 ]])
-LT_AT_EXEC_CHECK([./cprogram], 0, [expout])
+LT_AT_EXEC_CHECK([./cprogram], 0, [stdout])
+
+# A weaker output content check that is agnostic to the issues above.
+AT_CHECK([grep 'Welcome to GNU libtool mixed C/Fortran demo!' stdout],
+         [0], [ignore])
 ])
 
 
@@ -293,18 +302,6 @@ _LT_SETUP
 
 LT_AT_CHECK_CONFIG([--disable-shared],
                    [^build_old_libs=yes], [^build_libtool_libs=no])
-
-LT_AT_HOST_DATA([expout],
-[[ Welcome to GNU libtool Fortran demo!
- Real programmers write in FORTRAN.
- fsub called
- fsubf called
- fsub returned, saying that 2 *           2  =           4
- fsub is ok!
- fsub3 called
- fsub3 returned, saying that 4 *           2  =           8
- fsub3 is ok!
-]])
 _LT_CHECK_EXECUTE
 
 AT_CLEANUP
diff --git a/tests/fcdemo.at b/tests/fcdemo.at
index 0ade9bb..0ac4431 100644
--- a/tests/fcdemo.at
+++ b/tests/fcdemo.at
@@ -259,10 +259,10 @@ LT_AT_AUTOHEADER
 m4_define([_LT_CHECK_EXECUTE],
 [LT_AT_MAKE
 
-# Oddly, the output of dynamically linked fprogram differs depending
-# on whether it is redirected to a file or sent to stdout, so we
-# just check return status, and ignore output.
-# Advice on this weirdness from a Fortran user much appreciated!
+# Due to differences in line-endings between C stdout and Fortran
+# stdout, as well as unpredictable output ordering between platforms
+# and runtimes, we can't reliably check the output here... although
+# it should be some variation of the following:
 LT_AT_HOST_DATA([expout],
 [[ Welcome to GNU libtool Fortran demo!
  Real programmers write in FORTRAN.
@@ -274,8 +274,13 @@ LT_AT_HOST_DATA([expout],
  fsub3 returned, saying that 4 *           2  =           8
  fsub3 is ok!
 ]])
-LT_AT_EXEC_CHECK([./fprogram], 0, [ignore])
+LT_AT_EXEC_CHECK([./fprogram], 0, [stdout])
 
+# A weaker output content check that is agnostic to the issues above.
+AT_CHECK([grep 'Welcome to GNU libtool Fortran demo!' stdout],
+         [0], [ignore])
+
+# Similarly, we can't reliably compare actual output with the following.
 LT_AT_HOST_DATA([expout],
 [[Welcome to GNU libtool mixed C/Fortran demo!
 The C subroutine returned, claiming that 2*2 = 4
@@ -290,7 +295,11 @@ The C wrapper to the fortran subroutine returned,
 claiming that 2*2 = 4
 The Fortran subroutine is ok!
 ]])
-LT_AT_EXEC_CHECK([./cprogram], 0, [expout])
+LT_AT_EXEC_CHECK([./cprogram], 0, [stdout])
+
+# A weaker output content check that is agnostic to the issues above.
+AT_CHECK([grep 'Welcome to GNU libtool mixed C/Fortran demo!' stdout],
+         [0], [ignore])
 ])
 
 


hooks/post-receive
-- 
GNU Libtool