[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: |
Jim Meyering |
Subject: |
Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake |
Date: |
Mon, 06 Feb 2012 15:27:34 +0100 |
Stefano Lattarini wrote:
> 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.
...
> 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
s/to/too/
FYI, with this, all tests pass on Fedora 16.
I haven't reviewed the actual content.
- 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, 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/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