automake-patches
[Top][All Lists]
Advanced

[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: Stefano Lattarini
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Sun, 05 Feb 2012 14:16:59 +0100

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.

Thanks,
  Stefano

Attachment: 0001-tests-improve-and-rework-tests-on-dependency-trackin.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]