bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake

[Stefano Lattarini]

On 01/04/2012 08:57 PM, Jim Meyering wrote:
> (latest from git/master)
> I just ran the test suite using the latest and now we're down to 5 failures!
> 
>   # TOTAL: 2478
>   # PASS:  2382
>   # SKIP:  61
>   # XFAIL: 30
>   # FAIL:  5
>   # XPASS: 0
>   # ERROR: 0
> 
>   $ grep '^FAIL:' tests/test-suite.log
>   FAIL: depmod
>   FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
>   FAIL: depmod.tap 84 - tru64 [absolute VPATH] make & remake
>
About these failures, see also:
  <http://lists.gnu.org/archive/html/automake-patches/2011-05/msg00019.html>

> Started looking, and this one may be easy to fix:
> 
>   make[1]: Leaving directory 
> `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
>   make[1]: Entering directory 
> `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d'
>   make[1]: Nothing to be done for `all-am'.
>   make[1]: Leaving directory 
> `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d'
>   + make clean
>   Making clean in src
>   make[1]: Entering directory 
> `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
>   .deps/foo.Po:3: *** missing separator.  Stop.
>   make[1]: Leaving directory 
> `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
>   make: *** [clean-recursive] Error 1
>   + result_ 'not ok' 'tru64 [long VPATH] make & remake'
>   + set +x
>   not ok 50 - tru64 [long VPATH] make & remake
>   FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
>   + cd /h/j/w/co/automake/tests/depmod.dir
>   + not am_keeping_testdirs
> 
> Once you see the contents of the offending foo.Po file:
> (the "\:" on line 3 is the obvious culprit)
> 
>   $ cat tests/depmod.dir/tru64-long.d/src/.deps/foo.Po
>   foo.o: ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.c \
>    ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.h
>   ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.c \:
>    ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.h:
> 
> tap 84 fails for the same reason.
>
The fact is that these failures (as we can experience them, at least) only 
happen
when we are *forcing* the use of the tru64 depmode *to gcc* (which obviously 
isn't
really meant nor expected to handle it); OTOH, the failures do *not* happen with
the Sun C Compiler (5.9 on Solaris 10).  So the real question is: do such 
failures
take place with the Tru64 compiler?  If yes, we really have a bug to fix; if 
not,
the failure is merely a consequence of our messing with forced depmodes, and the
correct fix is to SKIP the affected tests.

Unfortunately, I don't have access to a Tru64 system, so I can't do the testing
myself.

Regards,
   Stefano