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.
