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

Previous Next

Full log

Message #32 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: automake-patches <at> gnu.org, 10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Tue, 07 Feb 2012 22:05:08 +0100

Stefano Lattarini skrev 2012-02-05 14:16:
> On 02/02/2012 11:41 PM, Peter Rosin wrote:
>> Stefano Lattarini skrev 2012-02-02 22:45:
>>> Reference:
>>>   <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434>
>>>
>>> OK, the attached patch fixes the two spurious failures of GCC forced into
>>> Tru64 mode.  About time I'd say.
>>>
>>> But I'm not sure whether we should apply this without first testing it
>>> on a real Tru64 compiler, lest we cause a real regression just to fix a
>>> spurious failure.  Thoughts?
>>
>> I just had a look at that test, and it seems like a very crappy test
>> to me.  I had some failures with cl, but figured it was the same as
>> these Tru64 failures that I had seen flying past, and put it all on
>> the back burner.  But the test is destined to cause troubles if IIUC.
>>
>> It's just dead wrong to assume that feeding -M or -xM to the compiler
>> (or whatever other random stuff depcomp might do) and not get an error
>> is the same as dependencies magically appearing.  Or do I read the
>> test wrong?  Please tell me that I do!
>>
> Unfortunately you read the test right.  And in hindsight I must agree
> with you: its approach is fundamentally flawed.
> 
> So, what about the attached patch, that overhauls (and hopefully improve)
> the coverage for automatic dependency tracking support?  It is probably
> possible to improve the patch even more (esp. w.r.t. optimizations for
> speed), but that can be left for follow-up changes IMHO.
> 
> I will push (to master) in 72 hours if there is no objection by then.

Hi Stefano,

This looks promising!

Appart from the below inline nitpicking, your method to force a depmode
doesn't really seem to work, possibly only when you also force another
compiler, as shown by the below grep (after a non-libtool run with
CC="cl- nologo").

$ grep "checking dependency style" tests/depcomp-*.log
tests/depcomp-auto.log:checking dependency style of cl -nologo... msvc7msys
tests/depcomp-auto.log:checking dependency style of cl -nologo... msvc7msys
tests/depcomp-auto.log:checking dependency style of cl -nologo... msvc7msys
tests/depcomp-auto.log:checking dependency style of cl -nologo... msvc7msys
tests/depcomp-cpp.log:checking dependency style of gcc... gcc3
tests/depcomp-cpp.log:checking dependency style of gcc... gcc3
tests/depcomp-cpp.log:checking dependency style of gcc... gcc3
tests/depcomp-cpp.log:checking dependency style of gcc... gcc3
tests/depcomp-dashXmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashXmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashXmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashXmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-disabled.log:checking dependency style of cl -nologo... none
tests/depcomp-disabled.log:checking dependency style of cl -nologo... none
tests/depcomp-disabled.log:checking dependency style of cl -nologo... none
tests/depcomp-disabled.log:checking dependency style of cl -nologo... none
tests/depcomp-gcc.log:checking dependency style of gcc... gcc3
tests/depcomp-gcc.log:checking dependency style of gcc... gcc3
tests/depcomp-gcc.log:checking dependency style of gcc... gcc3
tests/depcomp-gcc.log:checking dependency style of gcc... gcc3

Over to the nitpicking part...

> From 2008b6bd27bba6194856cb5a58eb8c5e700e35c8 Mon Sep 17 00:00:00 2001
> Message-Id: <2008b6bd27bba6194856cb5a58eb8c5e700e35c8.1328447619.git.stefano.lattarini <at> gmail.com>
> From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
> Date: Fri, 3 Feb 2012 15:05:48 +0100
> Subject: [PATCH] tests: improve and rework tests on dependency tracking
> 
> Fixes automake bug#10434.  Suggestion by Peter Rosin.
> 
> The 'depcomp.tap' test case worked by trying to unconditionally
> force the compiler in use by the testsuite to use, one by one, *all*
> the dependency modes known by the 'depcomp' script, and, for each
> such forced mode that was compatible enough with said compiler not
> to cause breakage in the basic compilation rules, checking that it
> was *also* good enough not to break remake rules in VPATH builds.
> 
> This seemed a good approach when this test was first introduced, as
> it apparently increased coverage for the less used and less tested
> dependency-tracking modes.  But in the log run it turned out the
> approach was actually in part to brittle, causing some annoying

too (but I later saw that Jim said the same)

> spurious failures (as with the Tru64 depmode forced on GCC, see
> automake bug#10434), and partly too forgiving, since, for some of
> the more corner-case dependency modes, the 'depcomp' script simply
> reverts to silently disabling dependency tracking when an error is
> encountered (this happened e.g., with the Tru64 depmode forced on
> the Sun C compiler 5.9), so that a passing test means nothing, and
> only gives a false sense of security.
> 
> As Peter Rosin put it, "it's just dead wrong to assume that feeding
> -M or -xM to the compiler (or whatever other random stuff 'depcomp'
> might do) and not get an error is the same as dependencies magically
> appearing".
> 
> So we get rid of this wrong approach, and in the process proceed to
> a complete overhaul of many of the tests on automatic dependency
> tracking, extending the offered coverage and rationalizing their
> organization.
> 
> * tests/decomp.sh: New helper script, used by several new

depcomp.sh

> autogenerated tests.
> * tests/gen-testsuite-part: Generate several tests based on the
> new 'decomp.sh' script.  Emit makefile code that declares their

depcomp.sh again

> dependency on that script, and that extends EXTRA_DIST in order
> to distribute it.
> * tests/depmod.tap: Remove.
*snip*
> diff --git a/.gitignore b/.gitignore
> index 46607dc..c95a193 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -53,6 +53,7 @@ Makefile
>  /tests/testsuite-part.am
>  /tests/*-w.tap
>  /tests/*-w.test
> +/tests/depcomp-*.tap
>  /tests/*.dir
>  /tests/*.log
>  /tests/*.trs
> diff --git a/tests/depcomp.sh b/tests/depcomp.sh
> new file mode 100755
> index 0000000..147e8ca
> --- /dev/null
> +++ b/tests/depcomp.sh
> @@ -0,0 +1,378 @@
*snip*
> +      $FGREP 'unknown directive' output && return 1
> +      rm -f output
> +      # Checks for stray files possible left around by less common

possibly

> +      # depmodes.
> +      find . -name '*.[ud]' | grep . && return 1
> +      return 0
*snip*
> +    skip_row_ 2 -r "automatic dependency tracking couldn't be activated"
> +  else
> +    command_ok_ "$pfx generated $po files look correct" $MAKE grep-test
> +    r=ok \
> +      && : "Some checks in the subdir." \
> +      && $sleep \
> +      && : "Ensure rebuild rules do really kick in." \

"Ensure rebuild rules really do kick in."

> +      && rewrite "$srcdir"/src/sub2/sub2foo.h echo 'choke me' \
> +      && cd src \
> +      && not $MAKE  \
*snip*

Cheers,
Peter (still with a *very* sketchy Internet connection...)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.