[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
From: |
Peter Rosin |
Subject: |
Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake |
Date: |
Tue, 07 Feb 2012 22:05:08 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 |
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: <address@hidden>
> From: Stefano Lattarini <address@hidden>
> 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...)
- Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake, Stefano Lattarini, 2012/02/02
- Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake, Peter Rosin, 2012/02/02
- Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake,
Peter Rosin <=
- Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake, Peter Rosin, 2012/02/07
- Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake, Stefano Lattarini, 2012/02/07
- Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake, Peter Rosin, 2012/02/07
- Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake, Stefano Lattarini, 2012/02/08