[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/5] Automake custom test driver using SRFI-64.

From: Eric Bavier
Subject: Re: [PATCH 0/5] Automake custom test driver using SRFI-64.
Date: Wed, 23 Mar 2016 23:15:45 -0500

On Thu, 24 Mar 2016 00:38:45 +0100
Mathieu Lirzin <address@hidden> wrote:

> Hello,
> this is the debugged version of a patch previously sent here:
> It is possible to directly checkout 'origin/wip-check' branch to review these
> patches.  Thanks.

In addition to the test status, I get messages like this when running
`make check`:

;;; note: source file /home/bavier/projects/guix/srfi/srfi-64.scm
;;;       newer than compiled 
PASS: tests/elpa.scm
./test-env: line 1: 19815 Terminated              
"/home/bavier/projects/guix/build/master/guix-daemon" --disable-chroot 
--substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL" 2> /dev/null

It seems that we don't compile any of the srfi/srfi-* source?

I don't recall seeing the "Terminated" messages before (anyone else
see this?), but this patch to seems to help:

--- a/
+++ b/
@@ -100,7 +100,8 @@ then
        --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL" 2>/dev/null &

-    trap "kill $daemon_pid ; rm -rf $NIX_STATE_DIR" EXIT
+    trap "kill $daemon_pid ; wait $daemon_pid 2>/dev/null ;
+          rm -rf $NIX_STATE_DIR" EXIT

 # Avoid issues that could stem from l10n, such as language/encoding

The result output seems more informative.  The counts include
individual tests within each tests/*.scm, correct?

Testsuite summary for GNU Guix 0.9.1
# TOTAL: 677
# PASS:  671
# SKIP:  6
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

I notice in the test-suite.log that logs are included from tests that
are skipped.  This seems appropriate, but it appears to also include
PASS output from other tests in that suite (e.g. all of tests/gexp.log
is included since two of the 49 tests are skipp). Is it possible to
include output from only the skipped tests?  I'm not familiar for the
trs spec.

Thanks for this work.  I had considered reworking the test suites with
Autoconf's AutoTest for better unity, but I think what you've done here
is quite a bit more elegant with less disruption.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]