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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10434 in the body.
You can then email your comments to 10434 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: bug-automake <at> gnu.org
Subject: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Wed, 04 Jan 2012 20:57:53 +0100

[Message part 1 (text/plain, inline)]

(latest from git/master)
I just ran the test suite using the latest and now we're down to 5 failures!

  # TOTAL: 2478
  # PASS:  2382
  # SKIP:  61
  # XFAIL: 30
  # FAIL:  5
  # XPASS: 0
  # ERROR: 0

  $ grep '^FAIL:' tests/test-suite.log
  FAIL: depmod
  FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
  FAIL: depmod.tap 84 - tru64 [absolute VPATH] make & remake
  FAIL: tap-bad-prog-w
  FAIL: tap-bad-prog-w.tap 2 - non-existent test is reported
  FAIL: tap-bad-prog-w.tap 3 - non-executable test is reported
  FAIL: tap-bad-prog-w.tap 4 - non-readable test is reported

Started looking, and this one may be easy to fix:

  make[1]: Leaving directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
  make[1]: Entering directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d'
  make[1]: Nothing to be done for `all-am'.
  make[1]: Leaving directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d'
  + make clean
  Making clean in src
  make[1]: Entering directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
  .deps/foo.Po:3: *** missing separator.  Stop.
  make[1]: Leaving directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
  make: *** [clean-recursive] Error 1
  + result_ 'not ok' 'tru64 [long VPATH] make & remake'
  + set +x
  not ok 50 - tru64 [long VPATH] make & remake
  FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
  + cd /h/j/w/co/automake/tests/depmod.dir
  + not am_keeping_testdirs

Once you see the contents of the offending foo.Po file:
(the "\:" on line 3 is the obvious culprit)

  $ cat tests/depmod.dir/tru64-long.d/src/.deps/foo.Po
  foo.o: ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.c \
   ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.h
  ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.c \:
   ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.h:

tap 84 fails for the same reason.

Here's the full log.

[test-suite.log.xz (application/octet-stream, attachment)]

Message #8 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Thu, 05 Jan 2012 09:18:51 +0100

On 01/04/2012 08:57 PM, Jim Meyering wrote:
> (latest from git/master)
> I just ran the test suite using the latest and now we're down to 5 failures!
> 
>   # TOTAL: 2478
>   # PASS:  2382
>   # SKIP:  61
>   # XFAIL: 30
>   # FAIL:  5
>   # XPASS: 0
>   # ERROR: 0
> 
>   $ grep '^FAIL:' tests/test-suite.log
>   FAIL: depmod
>   FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
>   FAIL: depmod.tap 84 - tru64 [absolute VPATH] make & remake
>
About these failures, see also:
  <http://lists.gnu.org/archive/html/automake-patches/2011-05/msg00019.html>

> Started looking, and this one may be easy to fix:
> 
>   make[1]: Leaving directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
>   make[1]: Entering directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d'
>   make[1]: Nothing to be done for `all-am'.
>   make[1]: Leaving directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d'
>   + make clean
>   Making clean in src
>   make[1]: Entering directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
>   .deps/foo.Po:3: *** missing separator.  Stop.
>   make[1]: Leaving directory `/h/j/w/co/automake/tests/depmod.dir/tru64-long.d/src'
>   make: *** [clean-recursive] Error 1
>   + result_ 'not ok' 'tru64 [long VPATH] make & remake'
>   + set +x
>   not ok 50 - tru64 [long VPATH] make & remake
>   FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
>   + cd /h/j/w/co/automake/tests/depmod.dir
>   + not am_keeping_testdirs
> 
> Once you see the contents of the offending foo.Po file:
> (the "\:" on line 3 is the obvious culprit)
> 
>   $ cat tests/depmod.dir/tru64-long.d/src/.deps/foo.Po
>   foo.o: ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.c \
>    ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.h
>   ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.c \:
>    ../../this-is/a-path/which-have/quite-a/long_long_name/src/foo.h:
> 
> tap 84 fails for the same reason.
>
The fact is that these failures (as we can experience them, at least) only happen
when we are *forcing* the use of the tru64 depmode *to gcc* (which obviously isn't
really meant nor expected to handle it); OTOH, the failures do *not* happen with
the Sun C Compiler (5.9 on Solaris 10).  So the real question is: do such failures
take place with the Tru64 compiler?  If yes, we really have a bug to fix; if not,
the failure is merely a consequence of our messing with forced depmodes, and the
correct fix is to SKIP the affected tests.

Unfortunately, I don't have access to a Tru64 system, so I can't do the testing
myself.

Regards,
   Stefano

Message #11 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Thu, 05 Jan 2012 09:56:46 +0100

Stefano Lattarini wrote:
...
> Unfortunately, I don't have access to a Tru64 system, so I can't do the testing
> myself.

Nor do I.

Message #14 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: automake-patches <at> gnu.org, 10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Thu, 02 Feb 2012 22:45:22 +0100

[Message part 1 (text/plain, inline)]

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?

Regards,
  Stefano

[0001-tru64-depcomp-handle-line-continuations-more-graciou.patch (text/x-diff, attachment)]

Message #17 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Jim Meyering <jim <at> meyering.net>, automake-patches <at> gnu.org,
	10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Thu, 02 Feb 2012 23:41:33 +0100

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!

gcc needs to be required, or something, or we will suffer from FAILs
with every other odd compiler (that doesn't deserve them).

Cheers,
Peter

Message #20 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Jim Meyering <jim <at> meyering.net>, automake-patches <at> gnu.org,
	10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Sun, 05 Feb 2012 14:16:59 +0100

[Message part 1 (text/plain, inline)]

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

[0001-tests-improve-and-rework-tests-on-dependency-trackin.patch (text/x-diff, attachment)]

Message #23 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Peter Rosin <peda <at> lysator.liu.se>, automake-patches <at> gnu.org,
	10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Mon, 06 Feb 2012 15:27:34 +0100

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.

Message #26 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Peter Rosin <peda <at> lysator.liu.se>, automake-patches <at> gnu.org,
	10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Mon, 06 Feb 2012 18:17:43 +0100

Hi Jim, thanks for the feedback.

On 02/06/2012 03:27 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
>
> [SNIP]
 >
>> 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/
>
Consider this fixed.

> FYI, with this, all tests pass on Fedora 16.
>
Thanks for the info; I must admit I had tested the patch there in
advance ;-)

> I haven't reviewed the actual content.
>
If you intend to review it later, take all the due time -- there's
no hurry to apply this patch.  Just let me know, so that I won't
push it before you have had time do a review.

Regards,
  Stefano

Message #29 received at 10434 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Peter Rosin <peda <at> lysator.liu.se>, automake-patches <at> gnu.org,
	10434 <at> debbugs.gnu.org
Subject: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Mon, 06 Feb 2012 20:06:38 +0100

Stefano Lattarini wrote:
> Hi Jim, thanks for the feedback.
>
> On 02/06/2012 03:27 PM, Jim Meyering wrote:
>> Stefano Lattarini wrote:
>>
>> [SNIP]
>  >
>>> 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/
>>
> Consider this fixed.
>
>> FYI, with this, all tests pass on Fedora 16.
>>
> Thanks for the info; I must admit I had tested the patch there in
> advance ;-)
>
>> I haven't reviewed the actual content.
>>
> If you intend to review it later, take all the due time -- there's
> no hurry to apply this patch.  Just let me know, so that I won't
> push it before you have had time do a review.

Thanks.  I glanced through it, but cannot claim to do it justice
in just 10 minutes.  Looks like it'd take too long to come up to speed.
I'll trust you on this one.

Message #32 received at 10434 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Tue, 07 Feb 2012 22:05:08 +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.

Hi Stefano,

This looks promising!

Appart from the below inline nitpicking, your method to force a depmode
doesn't really seem to work, possibly only when you also force another
compiler, as shown by the below grep (after a non-libtool run with
CC="cl- nologo").

$ grep "checking dependency style" tests/depcomp-*.log
tests/depcomp-auto.log:checking dependency style of cl -nologo... msvc7msys
tests/depcomp-auto.log:checking dependency style of cl -nologo... msvc7msys
tests/depcomp-auto.log:checking dependency style of cl -nologo... msvc7msys
tests/depcomp-auto.log:checking dependency style of cl -nologo... msvc7msys
tests/depcomp-cpp.log:checking dependency style of gcc... gcc3
tests/depcomp-cpp.log:checking dependency style of gcc... gcc3
tests/depcomp-cpp.log:checking dependency style of gcc... gcc3
tests/depcomp-cpp.log:checking dependency style of gcc... gcc3
tests/depcomp-dashXmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashXmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashXmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashXmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-dashmstdout.log:checking dependency style of gcc... gcc3
tests/depcomp-disabled.log:checking dependency style of cl -nologo... none
tests/depcomp-disabled.log:checking dependency style of cl -nologo... none
tests/depcomp-disabled.log:checking dependency style of cl -nologo... none
tests/depcomp-disabled.log:checking dependency style of cl -nologo... none
tests/depcomp-gcc.log:checking dependency style of gcc... gcc3
tests/depcomp-gcc.log:checking dependency style of gcc... gcc3
tests/depcomp-gcc.log:checking dependency style of gcc... gcc3
tests/depcomp-gcc.log:checking dependency style of gcc... gcc3

Over to the nitpicking part...

> From 2008b6bd27bba6194856cb5a58eb8c5e700e35c8 Mon Sep 17 00:00:00 2001
> Message-Id: <2008b6bd27bba6194856cb5a58eb8c5e700e35c8.1328447619.git.stefano.lattarini <at> gmail.com>
> From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
> Date: Fri, 3 Feb 2012 15:05:48 +0100
> 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

too (but I later saw that Jim said the same)

> spurious failures (as with the Tru64 depmode forced on GCC, see
> automake bug#10434), and partly too forgiving, since, for some of
> the more corner-case dependency modes, the 'depcomp' script simply
> reverts to silently disabling dependency tracking when an error is
> encountered (this happened e.g., with the Tru64 depmode forced on
> the Sun C compiler 5.9), so that a passing test means nothing, and
> only gives a false sense of security.
> 
> As Peter Rosin put it, "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".
> 
> So we get rid of this wrong approach, and in the process proceed to
> a complete overhaul of many of the tests on automatic dependency
> tracking, extending the offered coverage and rationalizing their
> organization.
> 
> * tests/decomp.sh: New helper script, used by several new

depcomp.sh

> autogenerated tests.
> * tests/gen-testsuite-part: Generate several tests based on the
> new 'decomp.sh' script.  Emit makefile code that declares their

depcomp.sh again

> dependency on that script, and that extends EXTRA_DIST in order
> to distribute it.
> * tests/depmod.tap: Remove.
*snip*
> diff --git a/.gitignore b/.gitignore
> index 46607dc..c95a193 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -53,6 +53,7 @@ Makefile
>  /tests/testsuite-part.am
>  /tests/*-w.tap
>  /tests/*-w.test
> +/tests/depcomp-*.tap
>  /tests/*.dir
>  /tests/*.log
>  /tests/*.trs
> 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*
> +      $FGREP 'unknown directive' output && return 1
> +      rm -f output
> +      # Checks for stray files possible left around by less common

possibly

> +      # depmodes.
> +      find . -name '*.[ud]' | grep . && return 1
> +      return 0
*snip*
> +    skip_row_ 2 -r "automatic dependency tracking couldn't be activated"
> +  else
> +    command_ok_ "$pfx generated $po files look correct" $MAKE grep-test
> +    r=ok \
> +      && : "Some checks in the subdir." \
> +      && $sleep \
> +      && : "Ensure rebuild rules do really kick in." \

"Ensure rebuild rules really do kick in."

> +      && rewrite "$srcdir"/src/sub2/sub2foo.h echo 'choke me' \
> +      && cd src \
> +      && not $MAKE  \
*snip*

Cheers,
Peter (still with a *very* sketchy Internet connection...)

Message #35 received at 10434 <at> debbugs.gnu.org (full text, mbox):

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

Message #38 received at 10434 <at> debbugs.gnu.org (full text, mbox):

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

Hi Peter, thanks for the invaluable feedback.

On 02/07/2012 10:05 PM, Peter Rosin wrote:
> Stefano Lattarini skrev 2012-02-05 14:16:
>
>> 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.
>
> Hi Stefano,
>
> This looks promising!
>
> Appart from the below inline nitpicking, your method to force a depmode
> doesn't really seem to work, possibly only when you also force another
> compiler, as shown by the below grep (after a non-libtool run with
> CC="cl- nologo").
>
Ouch (but then I see you found out and reported the reason for this
below -- thanks!).

> Over to the nitpicking part...
>
> [SNIP well-spotted nitpicks]
>
Consider all of those fixed.  Thanks.

>> 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
>
Well spotted! (and I feel like a moron now).  To make amend, I've squashed
the diff below into 'depmod.sh' (this would have caught the blunder right
away).

  @@ -262,12 +262,15 @@ test -f build-aux/depcomp \

   case $depmode in
     auto)
  +    displayed_depmode='.*'
       cfg_deptrack=--enable-dependency-tracking ;;
     disabled)
  +    displayed_depmode=none
       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'"
  +    displayed_depmode="(cached) $depmode"
       cfg_deptrack="cachevar=$depmode" ;;
  @@ -318,7 +321,15 @@ do_test ()
         ;;
     esac

  -  command_ok_ "$pfx configure" "$srcdir"/configure $cfg_deptrack ${1+"$@"}
  +  command_ok_ \
  +    "$pfx configure" \
  +    "$srcdir/configure" $cfg_deptrack ${1+"$@"} >stdout
  +  cat stdout
  +
  +  command_ok_ \
  +    "$pfx right depmode selected" \
  +    grep "^checking dependency style .*\.\.\. $displayed_depmode$" stdout
  +
     command_ok_ "$pfx simple make" make_ok
     # Some bugs in VPATH builds only kick in during a rebuild.
     command_ok_ "$pfx clean & rebuild" eval '$MAKE clean && make_ok'

I will push the patch by tomorrow, barring objections.

Thanks,
  Stefano

Message #41 received at 10434 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake
Date: Wed, 08 Feb 2012 00:29:21 +0100

Stefano Lattarini skrev 2012-02-08 00:01:
> Hi Peter, thanks for the invaluable feedback.

Thanks for the appreciation, but "invaluable" is perhaps a bit over the top...

> On 02/07/2012 10:05 PM, Peter Rosin wrote:
>> Stefano Lattarini skrev 2012-02-05 14:16:
>>> +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
>>
> Well spotted! (and I feel like a moron now).  To make amend, I've squashed
> the diff below into 'depmod.sh' (this would have caught the blunder right

<whisper>depcomp.sh</whisper>

> away).
> 
>   @@ -262,12 +262,15 @@ test -f build-aux/depcomp \
> 
>    case $depmode in
>      auto)
>   +    displayed_depmode='.*'
>        cfg_deptrack=--enable-dependency-tracking ;;
>      disabled)
>   +    displayed_depmode=none
>        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'"
>   +    displayed_depmode="(cached) $depmode"
>        cfg_deptrack="cachevar=$depmode" ;;
>   @@ -318,7 +321,15 @@ do_test ()
>          ;;
>      esac
> 
>   -  command_ok_ "$pfx configure" "$srcdir"/configure $cfg_deptrack ${1+"$@"}
>   +  command_ok_ \
>   +    "$pfx configure" \
>   +    "$srcdir/configure" $cfg_deptrack ${1+"$@"} >stdout
>   +  cat stdout
>   +
>   +  command_ok_ \
>   +    "$pfx right depmode selected" \
>   +    grep "^checking dependency style .*\.\.\. $displayed_depmode$" stdout
>   +
>      command_ok_ "$pfx simple make" make_ok
>      # Some bugs in VPATH builds only kick in during a rebuild.
>      command_ok_ "$pfx clean & rebuild" eval '$MAKE clean && make_ok'

Remember to also bump plan_...

> I will push the patch by tomorrow, barring objections.

And thanks for this new depcomp testing infrastructure!

Cheers,
Peter

Message #44 received at 10434 <at> debbugs.gnu.org (full text, mbox):

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

tags 10434 + patch
close 10434
thanks

On 02/08/2012 12:29 AM, Peter Rosin wrote:
> Stefano Lattarini skrev 2012-02-08 00:01:
>> Hi Peter, thanks for the invaluable feedback.
> 
> Thanks for the appreciation, but "invaluable" is perhaps a bit over
> the top...
>
Not for what concerns this patch IMHO.

> [SNIP]
>
> Remember to also bump plan_...
>
I had done that yesterday already (after a complain by
'depcomp-lt-auto.tap' that I was making it run too many
tests ;-)

Patch pushed now.  I'm thus closing this bug report.

Regards,
  Stefano

Previous Next

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