Re: [PATCH] {master} tests: extend tests on dependency tracking with VPATH

[Stefano Lattarini]

References:
 <http://lists.gnu.org/archive/html/automake-patches/2011-05/msg00007.html>
 <http://lists.gnu.org/archive/html/automake-patches/2011-04/msg00140.html>

On Tuesday 19 April 2011, Stefano Lattarini wrote:
> Hello Ralf.
> 
> On Monday 11 April 2011, Ralf Wildenhues wrote:
> > * Ralf Wildenhues wrote on Mon, Apr 11, 2011 at 07:13:00AM CEST:
> > >     Fix hp depmode for VPATH builds with GNU make.
> > >     
> > >     * lib/depcomp: Be sure to remove VPATH-prefixed object from
> > >     dependency output when creating stub rule.
> > >     * tests/depcomp10.test: New test.
> > >     * tests/Makefile.am (TESTS): Update.
> > >     * NEWS: Update.
> > >     Report by Bruno Haible.
> > 
> > Of course I should be merging this test and depcomp9, and generalizing
> > for all depmodes, and tuning my test scripts to exercise both make and
> > gmake on all systems.  (on my TODO list)
> > 
> I hope you don't mind if I've done this for you ;-)
> 
> See the attached patch.  I've tested it with pcc, gcc-2.95, gcc-3.4,
> gcc-4.4 and the Sun C compiler, and with GNU, BSD (Debian ports) and
> Heirloom make.

> Currently there is only one failure (with gcc >= 3 and NetBSD or GNU
> make and depmode=tru64, which I haven't tried to analyze yet (in any
> case, it isn't a regression, so we can tackle it in a follow-up).
> The log of this failure is attached, together with the content of the
> offending file `src/sub/.deps/subfoo.Po'.
> 
OK, I've now written a workaround for the gcc+tru64 failure; you can find
it attached.  But, lacking the possibility to test on a real Tru64, I
still don't know whether this failure is a spurious one (so that applying
my workaround is the way to go) or a real one (so that my workaround
would just sweep the dirt under the rug on GNU/Linux, only for the failure
to resurface later on Tru64).  Has anyone  the possibility to run the
`*.depmod' tests on a real Tru64 machine?  Here is how it can be done:

  $ git clone git://git.sv.gnu.org/automake.git
  $ cd automake
  $ git checkout testsuite-work
  $ ./configure && make
  $ cd tests
  $ CC=/path/to/tru64/c/compiler make check TESTS="\$(depmod_tests)" \
    AM_MAKEFLAGS="TESTS='\$(depmod_tests)'"

The test results can then be found in the `test-suite.log' file and in the
`depcomp-*.log' files.

Regards,
  Stefano

From cc89985b94564eadb994b75db44b0c98e655abdc Mon Sep 17 00:00:00 2001
Message-Id: <address@hidden>
From: Stefano Lattarini <address@hidden>
Date: Wed, 4 May 2011 10:01:18 +0200
Subject: [PATCH] depcomp tests defs: avoid a spurious failure (GCC + tru64 mode)

We used to skip a *.depmod test if the first "make all" failed,
because the depmode we forced might not actually work with the
compiler used.  Still, this is sometimes not enough, since few
forced depmodes might *seem* to work even with compilers which,
while being different from the one they are tailored to, happen
to support similar flags (though usually with a slightly but
fatally incompatible semantics).  So the first "make all" might
still succeeds also when the forced depmode is not truly supported
-- only for things to be silently screwed up later.  Sigh.
See for example:
<http://lists.gnu.org/archive/html/automake-patches/2011-04/msg00140.html>
So we try to rule out the known incompatibilities "by hand".

* tests/depmod-tests.sh (create_input_data): Update configure.in,
to skip on known invalid compiler/depmode combinations.
Update the ./configure call accordingly.
---
 ChangeLog             |   19 +++++++++++++++++++
 tests/depmod-tests.sh |   30 +++++++++++++++++++++++++++++-
 2 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index eda448e..e3d94ff 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+2011-05-04  Stefano Lattarini  <address@hidden>
+
+       depcomp tests defs: avoid a spurious failure (GCC + tru64 mode)
+       We used to skip a *.depmod test if the first "make all" failed,
+       because the depmode we forced might not actually work with the
+       compiler used.  Still, this is sometimes not enough, since few
+       forced depmodes might *seem* to work even with compilers which,
+       while being different from the one they are tailored to, happen
+       to support similar flags (though usually with a slightly but
+       fatally incompatible semantics).  So the first "make all" might
+       still succeeds also when the forced depmode is not truly supported
+       -- only for things to be silently screwed up later.  Sigh.
+       See for example:
+       
<http://lists.gnu.org/archive/html/automake-patches/2011-04/msg00140.html>
+       So we try to rule out the known incompatibilities "by hand".
+       * tests/depmod-tests.sh (create_input_data): Update configure.in,
+       to skip on known invalid compiler/depmode combinations.
+       Update the ./configure call accordingly.
+
 2011-05-03  Stefano Lattarini  <address@hidden>
 
        tests defs: one more environment sanitization (corner case)
diff --git a/tests/depmod-tests.sh b/tests/depmod-tests.sh
index 4eb8419..d9b7656 100755
--- a/tests/depmod-tests.sh
+++ b/tests/depmod-tests.sh
@@ -94,6 +94,25 @@ create_input_data ()
     AC_CONFIG_FILES([Makefile src/Makefile])
     AC_PROG_CC
     AM_PROG_CC_C_O
+    # Below, we skip the test if the first "make all" fails, because the
+    # depmode we force might not actually work with the current compiler.
+    # Still, this is sometimes not enough, since few forced depmodes might
+    # *seem* to work even with compilers which, while being different
+    # from the one they are tailored to, happen to support similar flags
+    # (though usually with a slightly but fatally incompatible semantics).
+    # So the first "make all" might still succeeds also when the forced
+    # depmode is not truly supported -- only for things to be silently
+    # screwed up later.  Sigh.  See for example:
+    #  
<http://lists.gnu.org/archive/html/automake-patches/2011-04/msg00140.html>
+    # So we try to rule out the known incompatibilities "by hand".
+    AC_MSG_CHECKING([whether the forced depmode is incompatible with your C 
compiler])
+    if test x"$GCC" = x"yes" \
+        && test $am_cv_CC_dependencies_compiler_type = tru64; then
+      AC_MSG_RESULT([yes])
+      AC_MSG_ERROR([depmode tru64 screws up with GCC], [66])
+   else
+      AC_MSG_RESULT([no])
+    fi
     AC_OUTPUT
 END
 
@@ -202,7 +221,16 @@ test -f ../depmod-data.dir/success || {
   Exit 99
 }
 
-../depmod-data.dir/configure am_cv_CC_dependencies_compiler_type=$depmode
+../depmod-data.dir/configure am_cv_CC_dependencies_compiler_type=$depmode \
+  || { st=$?;
+       if test $st -eq 66; then
+         skip_ "forced depmode '$depmode' unsafe with your compiler"
+       elif test $st -eq 77; then
+         skip_ "configure failed with status 77"
+       else
+         Exit 1
+       fi
+     }
 
 # Do not error out with the first make, as the depmode we've forced might
 # not actually work, but we have overridden the _AM_DEPENDENCIES tests.
-- 
1.7.2.3