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

Previous Next

Full log

View this message in rfc822 format

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: automake-patches <at> gnu.org, 10434 <at> debbugs.gnu.org
Subject: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Tue, 07 Feb 2012 22:39:11 +0100

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.
> 
> Thanks,
>   Stefano

*snip*

> 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*

> +case $depmode in
> +  auto)
> +    cfg_deptrack=--enable-dependency-tracking ;;
> +  disabled)
> +    cfg_deptrack=--disable-dependency-tracking ;;
> +  *)
> +    # Sanity check: ensure the cache variable we force is truly
> +    # used by configure.
> +    $FGREP $cachevar configure \
> +      || fatal_ "configure lacks required cache variable '$cachevar'"
> +    cfg_deptrack="cachevar=$depmode" ;;

Here's the reason for failing to force the depmode, possibly.

It works better with $cachevar

> +esac
> +
> +cd_top
> +

*snip*

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.