Bob Friesenhahn wrote:
>> Are you referring to the GraphicsMagick testsuite? If yes, it seems to me
>> that it could benefit greatly from the use of TAP once automake 1.12 is out;
>> for example, all the 314 'tests/rwfile*.sh' tests could be rewritten as one
>> single TAP test (and similarly for
On Sat, 31 Mar 2012, Russ Allbery wrote:
Bob Friesenhahn writes:
Ok, now I hear that there are still log files similar to parallel-tests
(presumably using the identical facility). It does not seem that Russ's
C TAP Harness offers this quite wonderful feature since the instructions
advise to
Bob Friesenhahn writes:
> Ok, now I hear that there are still log files similar to parallel-tests
> (presumably using the identical facility). It does not seem that Russ's
> C TAP Harness offers this quite wonderful feature since the instructions
> advise to re-run just the one test to see more
On Sun, 1 Apr 2012, Stefano Lattarini wrote:
On 03/31/2012 11:47 PM, Bob Friesenhahn wrote:
how does one re-execute just one test in order to see the details
of how it failed?
With Automake, one shouldn't -- he should write his test to be verbose
enough so that a perusing of the logs is suff
On 03/31/2012 11:20 PM, Bruce Korb wrote:
> On 03/31/12 13:58, Bruce Korb wrote:
>> On 03/31/12 13:44, Bruce Korb wrote:
>>
>> I didn't see it at first because of the comment that made it look like
>> something different from the "installcheck-am" rule. The problem
>> is a *partially* commented out
Stefano Lattarini writes:
> Consider that the whole point of the TAP support in Automake is that the
> testsuite harness present in Automake-generated makefiles (the one that
> gets launched by "make check") will act as TAP consumer itself. Thus
> the "harness" part of Russ' package is likely of
On 03/31/2012 11:47 PM, Bob Friesenhahn wrote:
>
> how does one re-execute just one test in order to see the details
> of how it failed?
>
With Automake, one shouldn't -- he should write his test to be verbose
enough so that a perusing of the logs is sufficient to reveal the reason
of the failure.
On 03/31/2012 10:23 PM, Bob Friesenhahn wrote:
> On Sat, 31 Mar 2012, Stefano Lattarini wrote:
>>>
>> Well, automake being automake, it only depends on portable awk[1] ;-)
>> OK, portable "nawk" actually (as found by the autoconf builtin macro
>> AC_PROG_AWK), but I don't know of any non-museum mac
Bob Friesenhahn writes:
> The numbers are useful. TAP is documented to support reporting the number
> of tests at the end of the test run rather than at the beginning.
Yes, that of course works as well. With the basic C TAP library, you can
use plan_lazy() instead of plan() and the library wil
On Sat, 31 Mar 2012, Russ Allbery wrote:
This isn't the case if you have a sufficiently new version of the TAP
driver. The TAP protocol allows the tests to not be numbered. You lose
some robustness, since you then potentially don't know if a test was
skipped silently, but it's supported by C TA
On 03/31/12 13:58, Bruce Korb wrote:
On 03/31/12 13:44, Bruce Korb wrote:
I didn't see it at first because of the comment that made it look like
something different from the "installcheck-am" rule. The problem
is a *partially* commented out maintainer-clean rule.
installcheck-am:
#maintainer-
Bob Friesenhahn writes:
> The philosophy of TAP is rather different than Automake's existing test
> suite. These differences may prove challenging when switching from
> Automake tests to TAP:
> * Every TAP test needs to somehow know its unique test number (so it
> can print a result "ok 3
On 03/31/12 13:44, Bruce Korb wrote:
I didn't see it at first because of the comment that made it look like
something different from the "installcheck-am" rule. The problem
is a *partially* commented out maintainer-clean rule.
installcheck-am:
#maintainer-clean: maintainer-clean-recursive
On 03/31/12 09:24, Bruce Korb wrote:
>installcheck-recursive> test -f xml2ag/Makefile
>installcheck-recursive> test no = no
>installcheck-recursive> make installcheck-am
GNU Make 3.82
[]
Must remake target `installcheck'.
Successfully remade target file `installcheck'.
$ ls xml2ag/Make*
ls
On Sat, 31 Mar 2012, Stefano Lattarini wrote:
Well, automake being automake, it only depends on portable awk[1] ;-)
OK, portable "nawk" actually (as found by the autoconf builtin macro
AC_PROG_AWK), but I don't know of any non-museum machine lacking that.
Good.
The new feature is already do
Hi Bob.
On 03/31/2012 07:15 PM, Bob Friesenhahn wrote:
> On Wed, 22 Feb 2012, Stefano Lattarini wrote:
>>>
>> Are you referring to the GraphicsMagick testsuite? If yes, it seems to me
>> that it could benefit greatly from the use of TAP once automake 1.12 is out;
>> for example, all the 314 'test
On Wed, 22 Feb 2012, Stefano Lattarini wrote:
Are you referring to the GraphicsMagick testsuite? If yes, it seems to me
that it could benefit greatly from the use of TAP once automake 1.12 is out;
for example, all the 314 'tests/rwfile*.sh' tests could be rewritten as one
single TAP test (and
On 03/31/2012 01:38 PM, Stefano Lattarini wrote:
> On 03/28/2012 02:19 PM, Stefano Lattarini wrote:
>> Hi Joseph, thanks for the feedback.
>> On 03/28/2012 01:24 PM, Joseph S. Myers wrote:
>>>
>>> Is there better transition documentation somewhere?
>>>
>> Nope, but it would be a good idea to prepar
On 03/31/12 01:34, Stefano Lattarini wrote:
Is this a known problem or do I need to investigate further?
The issue you're facing sounds new to me, so I say some more investigations
are warranted. Could you maybe post a minimal reproducer of the issue here,
so that we can decide whether it is a
On Wed, 22 Feb 2012, Stefano Lattarini wrote:
Hi Bob, sorry for the delay.
On 02/19/2012 07:55 PM, Bob Friesenhahn wrote:
I am again bit by automake not being able run the test suite on systems
with bounded command line length. Up to automake 1.11.2 I was able to
apply a patch by Ralf Wildenh
On 03/28/2012 02:19 PM, Stefano Lattarini wrote:
> Hi Joseph, thanks for the feedback.
> On 03/28/2012 01:24 PM, Joseph S. Myers wrote:
>>
>> Is there better transition documentation somewhere?
>>
> Nope, but it would be a good idea to prepare it before starting to deprecate
> the 'cygnus' option.
Hi Alfred.
On 03/31/2012 11:08 AM, Alfred M. Szmidt wrote:
> - Have them distributed (automake's default). This means that
>they will be build in the srcdir, not in the builddir: of
>course, this only affects the maintainer, since for a user that
>builds the package f
- Have them distributed (automake's default). This means that
they will be build in the srcdir, not in the builddir: of
course, this only affects the maintainer, since for a user that
builds the package from a tarball those files should *not* be
rebuilt, hence ther
Hi Bruce, sorry for the delay.
On 03/31/2012 12:19 AM, Bruce Korb wrote:
> On 03/29/12 16:37, Bruce Korb wrote:
>> My tool versions, an edited transcript with the failure message and then
>> a help request.
>
> I modified the top level Makefile thus:
>
> [SNIP]
>
> and determined that "installch
Hi Ian, Joseph, and sorry for the delay.
On 03/29/2012 01:43 AM, Ian Lance Taylor wrote:
> Stefano Lattarini writes:
>
>>> (I think avoiding info documentation being built in the source directory,
>>> so that builds could use a non-writable source directory, may have been
>>> one part).
>>>
>> T
25 matches
Mail list logo
