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

[Peter Rosin]

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*