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

[Jim Meyering]

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.