| Message ID | 20221007205352.1282-1-maximedevos@telenet.be |
|---|---|
| State | New |
| Headers | show |
| Series | Support #:tests? in guile-build-system | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git-branch | success | View Git branch |
| cbaines/applying patch | success | |
| cbaines/issue | success | View issue |
| cbaines/comparison | success | View comparision |
| cbaines/git-branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
Hello, Maxime Devos <maximedevos@telenet.be> skribis: > A copy is made of test-driver.scm to avoid potentially surprising rebuilds > when changes are made. > > * gnu/packages/guile.scm (guile-test-driver): New variable. > * gnu/packages/aux-files/test-driver.scm: New file. > * Makefile.am (AUX_FILES): Register it. > * build-aux/test-driver.scm: Add a note. I very much like the idea of supporting #:tests? in ‘guile-build-system’, but I’m skeptical about this approach. The reason I’m skeptical is because ‘test-driver.scm’ is written as an Automake test driver (it follows the “protocol” defined by Automake) for tests that use SRFI-64—that’s a specific kind of tool, and one approach to writing test suites in Guile. I guess all I’m saying is that I doubt this is widely applicable, which the diff seems to confirm: > 4 files changed, 326 insertions(+), 2 deletions(-) Perhaps at this stage there really isn’t much we can factorize, after all. It would be nice to fix this, but that’s probably work to be done upstream—for example, by adding a “guild test” command. We can even beta-test such a command as an external project before including it in Guile proper. WDYT? Thanks, Ludo’.
On 18-10-2022 14:36, Ludovic Courtès wrote: > Hello, > > Maxime Devos <maximedevos@telenet.be> skribis: > >> A copy is made of test-driver.scm to avoid potentially surprising rebuilds >> when changes are made. >> >> * gnu/packages/guile.scm (guile-test-driver): New variable. >> * gnu/packages/aux-files/test-driver.scm: New file. >> * Makefile.am (AUX_FILES): Register it. >> * build-aux/test-driver.scm: Add a note. > > I very much like the idea of supporting #:tests? in > ‘guile-build-system’, but I’m skeptical about this approach. > > The reason I’m skeptical is because ‘test-driver.scm’ is written as an > Automake test driver (it follows the “protocol” defined by Automake) It is perfectly usable outside Automake, as this patch series demonstrates -- it does not depend on any Automake details. Also, the alternative would be to do "guile -l the-test-suite.scm" directly (without a test runner) -- while sometimes this works, sometimes the SRFI-64 implementation really cares that there is actually some test runner (I got a failure for some unpackaged Scheme library when running it without test-driver.scm), and additionally IMO the output of "guile -l the-test-suite.scm" isn't very nice, the test-driver.scm has much more nice output and is more consistent with other packages' test output. (A third alternative would be to ignore the tests altogether, but running tests is good and I have some patches for adding support for the tests.) > for tests that use SRFI-64— That's the standard Scheme API for test suites in Scheme -- widely applicable. (There's also SRFI-78, but that's currently unsupported by Guile, so it's currently not relevant for guile-build-system.) > that’s a specific kind of tool, and one approach > to writing test suites in Guile. It's the only approach to my knowledge, aside from 'let's just put a bunch of (when wrong? (error ...)) in a script and do 'guile -l the-script.scm' or reimplement our own thing, but that's not a nice approach, I would rather make it possible to use the more-standard and nicer (even though it's somewhat stateful) SRFI-64. Also, I don't see what's wrong with 'specific kind of tools' -- should we remove 'nml' then because it's super-specific to openttd? And even if there exists another tool that would fit here, why would that matter? I mean, the 'gcc' approach to compiling C wasn't rejected in Guix even though it's just 'one' approach to compiling C -- for example, 'clang' is another approach. If someone has another approach to running SRFI-64 test suites in guile-build-system, they can propose it and it can be discussed which one would be better for guile-build-system. Additionally, a nitpick -- test-driver.scm is an approach to running (SRFI-64) test suites, not for writing them, for writing test suites, SRFI-64 is an approach. > I guess all I’m saying is that I doubt this is widely applicable, which > the diff seems to confirm: > >> 4 files changed, 326 insertions(+), 2 deletions(-) I don't how you get from the diff that it isn't widely applicable -- it is applicable to every package that has a SRFI-64 test suite and uses guile-build-system. I just didn't check every guile-build-system thing for whether it has a SRFI-64 test suite. And once more Scheme libraries are packaged (especially Scheme libraries not written with Guile in mind, where gnu-build-system is likely inapplicable), presumably we would get more packages where this patch series can run tests. Additionally, have you considered that one possible reason for lack of SRFI-64 test suites in guile-build-system packages, is that previously there was no good method to run those test suites, so (for someone using Guix and Guile) writing them would be pointless? > Perhaps at this stage there really isn’t much we can factorize, after > all. It would be nice to fix this, I don't see any problem to fix or anything to factorize. What is this 'this' you are referring to? > but that’s probably work to be done > upstream—for example, by adding a “guild test” command. Going by "git log build-aux/test-driver.scm", Guix is the upstream, not Guile, though I suppose it could eventually be moved to Guile if desired by both. > We can even > beta-test such a command as an external project before including it in > Guile proper. > > WDYT? I think it already has seen plenty of testing -- in Guix, in scheme-gnunet, I think I've also seen it used in the GnuTLS bindings, likely by most other Guile programs that use gnu-build-system and have a test suite as well. I mean, it existed since 2015 according to "git log", that's 7 years of testing, seems plenty to me, and it also has been used by various projects. Greetings, Maxime.
Hi Maxime, That’s quite a wall of text that you sent. :-) Let me try to clarify what I think can be a fruitful way forward. Again, I agree with the goal you have here, I’m just proposing a different strategy. To me, the problem that we have is lack of a standard way to run tests in Guile packages that don’t use Autotools. That, in turn, leads to duplication in package definitions—whether it’s ‘check’ phases in Guix or something similar in Debian and other distros. Instead of addressing it downstream (in Guix), my suggestion would be to address it upstream—that is, to promote one way to run SRFI-64 test suites, for example with a new “guild test” command. That “guild test” command would probably be very similar to ‘build-aux/test-driver.scm’. As you note, this script is battle-tested and provides useful functionality. If we would turn it into a (scripts test) module, that ‘guild’ would pick up, then we’d have a good start. With proper documentation, programmers who use Guile would have an incentive to use this method; packagers would benefit because the default ‘check’ phase would boil down to invoking “guild test”. I hope this clarifies my proposal. WDYT? Thanks, Ludo’.
Hi, Op 18-10-2022 om 17:44 schreef Ludovic Courtès: > Hi Maxime, > > That’s quite a wall of text that you sent. :-) Going by the definition at ‘https://en.wikipedia.org/wiki/Wikipedia:Wall_of_text’, it isn't -- it is not intentionally disruptive (neither unintentionally disruptive), it is not an attempt at overwhelmening, it is not irrelevant and AFAICT it is not due to an unawareness of good practices. The only ‘wall-of-text’ property it might have is its length. So, you're apparently ignoring all what I wrote previously? > Let me try to clarify what I think can be a fruitful way forward. > Again, I agree with the goal you have here, I’m just proposing a > different strategy. > > To me, the problem that we have is lack of a standard way to run tests > in Guile packages that don’t use Autotools. That, in turn, leads to > duplication in package definitions—whether it’s ‘check’ phases in Guix > or something similar in Debian and other distros. Err, this is the same for Autotools Guile packages -- Autotools Guile packages have to copy test-driver.scm too (or do (exit 1)-style tests, but those aren't really the tests this patch series). You can drop the qualifier ‘ Also, there is, in fact a standard way to run tests in Guile packages: copy the test-driver.scm (and in case of Autotools, parts of the Makefile.am from another Guile package). While this does sound like _a_ problem, it is not a problem this patch series is about and hence not _the_ problem (see later for details). > Instead of addressing it downstream (in Guix), my suggestion would be to > address it upstream—that is, to promote one way to run SRFI-64 test > suites, for example with a new “guild test” command. But Guix is the upstream (I mentioned this in the first e-mail *) -- AFAICT, Guix has the latest version of test-driver.scm, and AFAICT Guix is where test-driver.scm + parts of Makefile.am is copied from. (*) and also right in the e-mail you were responding to: > Going by "git log build-aux/test-driver.scm", Guix is the upstream, not > Guile, though I suppose it could eventually be moved to Guile if desired > by both. See, I can make claims too. The difference is that you multiply times claimed things _without_ evidence whereas when I claimed the contrary _with_ evidence. ... did you even read it? My ‘wall of text’ wasn't for show. > That “guild test” command would probably be very similar to > ‘build-aux/test-driver.scm’. As you note, this script is battle-tested > and provides useful functionality. If we would turn it into a (scripts > test) module, that ‘guild’ would pick up, then we’d have a good start. > With proper documentation, programmers who use Guile would have an > incentive to use this method; packagers would benefit because the > default ‘check’ phase would boil down to invoking “guild test”. > > I hope this clarifies my proposal. WDYT? I think that is a clear proposal, I'm not interested in implementing it, I consider it out-of-scope and something that could be done separately from this patch series, and I won't do it, no matter that you are presenting it as if it were natural for me to do so -- I'm not paid enough for this and don't want your money. Finding who should be the upstream of test-driver.scm or finding a new home for test-driver.scm is not at all the point of this patch series -- the point is to support #:tests? in guile-build-system, and for that a test driver is needed, and look, there is a test driver right here in the Guix repo, let's package it so that it becomes available to the build/test code of guile-build-system (and as a bonus, it makes test-driver.scm more discoverable). IOW, going back to your ‘I'm just proposing a different strategy’ comment -- you aren't proposing a different strategy for the patch series, you are proposing something supplemental, and that ‘something supplemental’ is something for guile-devel@, not guix@. Best regards (except to Ludo (*)), Maxime Devos (*) because of the unconstructive and disrespectful PMs, and other reasons
(Some context I forgot to include:) Around the same time at the last previous message on technical matters (https://issues.guix.gnu.org/58365#9), Ludo' sent a PM on some non-technical matters, and I answered to the PM instead of 58365, leaving the technical matters message unreplied. So, now, at last, a reply.
Top posting to make sure it is read: Maxime: I understand this has been going back and forth for over a year now and has been very frustrating, but parts of this email are unnecessary. As a maintainer I haven't done enough to try to ease tensions and find an equitable solution and for that I apologize. Ludo: Based on the publicly available emails I'm not seeing why this was held in limbo for so long. For plenty of packages we have a policy of writing a patch, submitting it upstream if possible, and carrying it until we can drop it. Currently I'm not seeing this as so much different as either that case or some of the other files we carry in gnu/packages/aux-files. To everyone: Please keep in mind if you feel the need to remove the mailing list from the reply chain if it is because it is something that really, truly, doesn't need to be sent to everyone or because you'd rather have it hidden from view. I am liberally removing parts of the email as I respond below: On Mon, Nov 20, 2023 at 01:34:12AM +0100, Maxime Devos wrote: > Hi, > > Op 18-10-2022 om 17:44 schreef Ludovic Courtès: > > Let me try to clarify what I think can be a fruitful way forward. > > Again, I agree with the goal you have here, I’m just proposing a > > different strategy. Noted > > To me, the problem that we have is lack of a standard way to run tests > > in Guile packages that don’t use Autotools. That, in turn, leads to > > duplication in package definitions—whether it’s ‘check’ phases in Guix > > or something similar in Debian and other distros. Noted > Err, this is the same for Autotools Guile packages -- Autotools Guile > packages have to copy test-driver.scm too (or do (exit 1)-style tests, but > those aren't really the tests this patch series). You can drop the > qualifier ‘ > > Also, there is, in fact a standard way to run tests in Guile packages: copy > the test-driver.scm (and in case of Autotools, parts of the Makefile.am from > another Guile package). > > While this does sound like _a_ problem, it is not a problem this patch > series is about and hence not _the_ problem (see later for details). Noted. Referring back to duplicated code above from Ludo, I wonder about using the test-driver script by default vs adding it per-package, but I don't have a good handle on how many packages are waiting to use it. > > Instead of addressing it downstream (in Guix), my suggestion would be to > > address it upstream—that is, to promote one way to run SRFI-64 test > > suites, for example with a new “guild test” command. > > But Guix is the upstream (I mentioned this in the first e-mail *) -- AFAICT, > Guix has the latest version of test-driver.scm, and AFAICT Guix is where > test-driver.scm + parts of Makefile.am is copied from. > > (*) and also right in the e-mail you were responding to: Sounds like Guix is the upstream of test-driver.scm and guile, as the upstream language in this build-system, could absorb it and make it available through 'guild test'. > > Going by "git log build-aux/test-driver.scm", Guix is the upstream, not > > Guile, though I suppose it could eventually be moved to Guile if desired > > by both. > > > That “guild test” command would probably be very similar to > > ‘build-aux/test-driver.scm’. As you note, this script is battle-tested > > and provides useful functionality. If we would turn it into a (scripts > > test) module, that ‘guild’ would pick up, then we’d have a good start. > > With proper documentation, programmers who use Guile would have an > > incentive to use this method; packagers would benefit because the > > default ‘check’ phase would boil down to invoking “guild test”. > > > > I hope this clarifies my proposal. WDYT? Sounds like a good long-term plan. That said, it is something to work out at a later date, not in this patch series. > I think that is a clear proposal, I'm not interested in implementing it, I > consider it out-of-scope and something that could be done separately from > this patch series. Noted > Finding who should be the upstream of test-driver.scm or finding a new home > for test-driver.scm is not at all the point of this patch series -- the > point is to support #:tests? in guile-build-system, and for that a test > driver is needed, and look, there is a test driver right here in the Guix > repo, let's package it so that it becomes available to the build/test code > of guile-build-system (and as a bonus, it makes test-driver.scm more > discoverable). Sounds reasonable. > IOW, going back to your ‘I'm just proposing a different strategy’ comment -- > you aren't proposing a different strategy for the patch series, you are > proposing something supplemental, and that ‘something supplemental’ is > something for guile-devel@, not guix@. I ignored this the first time through because it has to do with the guile-build-system and that's not something I've ever looked at. It sounds like the best *long term* option is to move this upstream to guile or to package it separately in its own repository. Seeing as it's been a year since this thread started I don't see that as a reason to hold anything up. In the immediate term, it looks like this patch set (which I haven't tested, but noticed the patches seem to be in the wrong order) would bring testing to the guile packages, which everyone agrees is a Good Thing™. Lets get it fixed up and merged and any other bits can be worked on at a later date. If no one else comes forward to make sure that all the pieces work the way they're supposed to I will take care of it myself in about a week. In the mean time, please try to keep the conversation at least civil, and remember that we're all bound by the Code of Conduct while involved with Guix.
diff --git a/Makefile.am b/Makefile.am index bfabf0bf2e..e1f1a4573e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -427,7 +427,8 @@ AUX_FILES = \ gnu/packages/aux-files/python/sanity-check.py \ gnu/packages/aux-files/python/sitecustomize.py \ gnu/packages/aux-files/renpy/renpy.in \ - gnu/packages/aux-files/run-in-namespace.c + gnu/packages/aux-files/run-in-namespace.c \ + gnu/packages/aux-files/test-driver.scm # Templates, examples. EXAMPLES = \ diff --git a/build-aux/test-driver.scm b/build-aux/test-driver.scm index 1cdd4ff8f7..7ff8d45031 100755 --- a/build-aux/test-driver.scm +++ b/build-aux/test-driver.scm @@ -2,6 +2,8 @@ exec guile --no-auto-compile -e main -s "$0" "$@" !# ;;;; test-driver.scm - Guile test driver for Automake testsuite harness +;;;; When update this code, consider updating +;;;; gnu/packages/aux-files/test-driver.scm as well. (define script-version "2021-02-02.05") ;UTC diff --git a/gnu/packages/aux-files/test-driver.scm b/gnu/packages/aux-files/test-driver.scm new file mode 100755 index 0000000000..1cdd4ff8f7 --- /dev/null +++ b/gnu/packages/aux-files/test-driver.scm @@ -0,0 +1,284 @@ +#!/bin/sh +exec guile --no-auto-compile -e main -s "$0" "$@" +!# +;;;; test-driver.scm - Guile test driver for Automake testsuite harness + +(define script-version "2021-02-02.05") ;UTC + +;;; Copyright © 2015, 2016 Mathieu Lirzin <mthl@gnu.org> +;;; Copyright © 2021 Maxim Cournoyer <maxim.cournoyer@gmail.com> +;;; +;;; This program is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; This program is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with this program. If not, see <http://www.gnu.org/licenses/>. + +;;;; Commentary: +;;; +;;; This script provides a Guile test driver using the SRFI-64 Scheme API for +;;; test suites. SRFI-64 is distributed with Guile since version 2.0.9. +;;; +;;;; Code: + +(use-modules (ice-9 format) + (ice-9 getopt-long) + (ice-9 pretty-print) + (ice-9 regex) + (srfi srfi-1) + (srfi srfi-19) + (srfi srfi-26) + (srfi srfi-64)) + +(define (show-help) + (display "Usage: + test-driver --test-name=NAME --log-file=PATH --trs-file=PATH + [--expect-failure={yes|no}] [--color-tests={yes|no}] + [--select=REGEXP] [--exclude=REGEXP] [--errors-only={yes|no}] + [--enable-hard-errors={yes|no}] [--brief={yes|no}}] + [--show-duration={yes|no}] [--] + TEST-SCRIPT [TEST-SCRIPT-ARGUMENTS] +The '--test-name' option is mandatory. The '--select' and '--exclude' options +allow selecting or excluding individual test cases via a regexp, respectively. +The '--errors-only' option can be set to \"yes\" to limit the logged test case +metadata to only those test cases that failed. When set to \"yes\", the +'--brief' option disables printing the individual test case result to the +console. When '--show-duration' is set to \"yes\", the time elapsed per test +case is shown.\n")) + +(define %options + '((test-name (value #t)) + (log-file (value #t)) + (trs-file (value #t)) + (select (value #t)) + (exclude (value #t)) + (errors-only (value #t)) + (color-tests (value #t)) + (expect-failure (value #t)) ;XXX: not implemented yet + (enable-hard-errors (value #t)) ;not implemented in SRFI-64 + (brief (value #t)) + (show-duration (value #t)) + (help (single-char #\h) (value #f)) + (version (single-char #\V) (value #f)))) + +(define (option->boolean options key) + "Return #t if the value associated with KEY in OPTIONS is \"yes\"." + (and=> (option-ref options key #f) (cut string=? <> "yes"))) + +(define* (test-display field value #:optional (port (current-output-port)) + #:key pretty?) + "Display \"FIELD: VALUE\\n\" on PORT." + (if pretty? + (begin + (format port "~A:~%" field) + (pretty-print value port #:per-line-prefix "+ ")) + (format port "~A: ~S~%" field value))) + +(define* (result->string symbol #:key colorize?) + "Return SYMBOL as an upper case string. Use colors when COLORIZE is #t." + (let ((result (string-upcase (symbol->string symbol)))) + (if colorize? + (string-append (case symbol + ((pass) "[0;32m") ;green + ((xfail) "[1;32m") ;light green + ((skip) "[1;34m") ;blue + ((fail xpass) "[0;31m") ;red + ((error) "[0;35m")) ;magenta + result + "[m") ;no color + result))) + + +;;; +;;; SRFI 64 custom test runner. +;;; + +(define* (test-runner-gnu test-name #:key color? brief? errors-only? + show-duration? + (out-port (current-output-port)) + (trs-port (%make-void-port "w")) + select exclude) + "Return an custom SRFI-64 test runner. TEST-NAME is a string specifying the +file name of the current the test. COLOR? specifies whether to use colors. +When BRIEF? is true, the individual test cases results are masked and only the +summary is shown. ERRORS-ONLY? reduces the amount of test case metadata +logged to only that of the failed test cases. OUT-PORT and TRS-PORT must be +output ports. OUT-PORT defaults to the current output port, while TRS-PORT +defaults to a void port, which means no TRS output is logged. SELECT and +EXCLUDE may take a regular expression to select or exclude individual test +cases based on their names." + + (define test-cases-start-time (make-hash-table)) + + (define (test-on-test-begin-gnu runner) + ;; Procedure called at the start of an individual test case, before the + ;; test expression (and expected value) are evaluated. + (let ((test-case-name (test-runner-test-name runner)) + (start-time (current-time time-monotonic))) + (hash-set! test-cases-start-time test-case-name start-time))) + + (define (test-skipped? runner) + (eq? 'skip (test-result-kind runner))) + + (define (test-failed? runner) + (not (or (test-passed? runner) + (test-skipped? runner)))) + + (define (test-on-test-end-gnu runner) + ;; Procedure called at the end of an individual test case, when the result + ;; of the test is available. + (let* ((results (test-result-alist runner)) + (result? (cut assq <> results)) + (result (cut assq-ref results <>)) + (test-case-name (test-runner-test-name runner)) + (start (hash-ref test-cases-start-time test-case-name)) + (end (current-time time-monotonic)) + (time-elapsed (time-difference end start)) + (time-elapsed-seconds (+ (time-second time-elapsed) + (* 1e-9 (time-nanosecond time-elapsed))))) + (unless (or brief? (and errors-only? (test-skipped? runner))) + ;; Display the result of each test case on the console. + (format out-port "~a: ~a - ~a ~@[[~,3fs]~]~%" + (result->string (test-result-kind runner) #:colorize? color?) + test-name test-case-name + (and show-duration? time-elapsed-seconds))) + + (unless (and errors-only? (not (test-failed? runner))) + (format #t "test-name: ~A~%" (result 'test-name)) + (format #t "location: ~A~%" + (string-append (result 'source-file) ":" + (number->string (result 'source-line)))) + (test-display "source" (result 'source-form) #:pretty? #t) + (when (result? 'expected-value) + (test-display "expected-value" (result 'expected-value))) + (when (result? 'expected-error) + (test-display "expected-error" (result 'expected-error) #:pretty? #t)) + (when (result? 'actual-value) + (test-display "actual-value" (result 'actual-value))) + (when (result? 'actual-error) + (test-display "actual-error" (result 'actual-error) #:pretty? #t)) + (format #t "result: ~a~%" (result->string (result 'result-kind))) + (newline)) + + (format trs-port ":test-result: ~A ~A [~,3fs]~%" + (result->string (test-result-kind runner)) + (test-runner-test-name runner) time-elapsed-seconds))) + + (define (test-on-group-end-gnu runner) + ;; Procedure called by a 'test-end', including at the end of a test-group. + (let ((fail (or (positive? (test-runner-fail-count runner)) + (positive? (test-runner-xpass-count runner)))) + (skip (or (positive? (test-runner-skip-count runner)) + (positive? (test-runner-xfail-count runner))))) + ;; XXX: The global results need some refinements for XPASS. + (format trs-port ":global-test-result: ~A~%" + (if fail "FAIL" (if skip "SKIP" "PASS"))) + (format trs-port ":recheck: ~A~%" + (if fail "yes" "no")) + (format trs-port ":copy-in-global-log: ~A~%" + (if (or fail skip) "yes" "no")) + (when brief? + ;; Display the global test group result on the console. + (format out-port "~A: ~A~%" + (result->string (if fail 'fail (if skip 'skip 'pass)) + #:colorize? color?) + test-name)) + #f)) + + (let ((runner (test-runner-null))) + (test-runner-on-test-begin! runner test-on-test-begin-gnu) + (test-runner-on-test-end! runner test-on-test-end-gnu) + (test-runner-on-group-end! runner test-on-group-end-gnu) + (test-runner-on-bad-end-name! runner test-on-bad-end-name-simple) + runner)) + + +;;; +;;; SRFI 64 test specifiers. +;;; +(define (test-match-name* regexp) + "Return a test specifier that matches a test name against REGEXP." + (lambda (runner) + (string-match regexp (test-runner-test-name runner)))) + +(define (test-match-name*/negated regexp) + "Return a negated test specifier version of test-match-name*." + (lambda (runner) + (not (string-match regexp (test-runner-test-name runner))))) + +;;; XXX: test-match-all is a syntax, which isn't convenient to use with a list +;;; of test specifiers computed at run time. Copy this SRFI 64 internal +;;; definition here, which is the procedural equivalent of 'test-match-all'. +(define (%test-match-all . pred-list) + (lambda (runner) + (let ((result #t)) + (let loop ((l pred-list)) + (if (null? l) + result + (begin + (if (not ((car l) runner)) + (set! result #f)) + (loop (cdr l)))))))) + + +;;; +;;; Entry point. +;;; + +(define (main . args) + (let* ((opts (getopt-long (command-line) %options)) + (option (cut option-ref opts <> <>))) + (cond + ((option 'help #f) (show-help)) + ((option 'version #f) (format #t "test-driver.scm ~A~%" script-version)) + (else + (let* ((log (and=> (option 'log-file #f) (cut open-file <> "w0"))) + (trs (and=> (option 'trs-file #f) (cut open-file <> "wl"))) + (out (duplicate-port (current-output-port) "wl")) + (test-name (option 'test-name #f)) + (select (option 'select #f)) + (exclude (option 'exclude #f)) + (test-specifiers (filter-map + identity + (list (and=> select test-match-name*) + (and=> exclude test-match-name*/negated)))) + (test-specifier (apply %test-match-all test-specifiers)) + (color-tests (if (assoc 'color-tests opts) + (option->boolean opts 'color-tests) + #t))) + (when log + (redirect-port log (current-output-port)) + (redirect-port log (current-warning-port)) + (redirect-port log (current-error-port))) + (test-with-runner + (test-runner-gnu test-name + #:color? color-tests + #:brief? (option->boolean opts 'brief) + #:errors-only? (option->boolean opts 'errors-only) + #:show-duration? (option->boolean + opts 'show-duration) + #:out-port out #:trs-port trs) + (test-apply test-specifier + (lambda _ + (load-from-path test-name)))) + (and=> log close-port) + (and=> trs close-port) + (close-port out)))) + (exit 0))) + +;;; Local Variables: +;;; eval: (add-hook 'write-file-functions 'time-stamp) +;;; time-stamp-start: "(define script-version \"" +;;; time-stamp-format: "%:y-%02m-%02d.%02H" +;;; time-stamp-time-zone: "UTC" +;;; time-stamp-end: "\") ;UTC" +;;; End: + +;;;; test-driver.scm ends here. diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm index fcdf75051c..b847ee6be4 100644 --- a/gnu/packages/guile.scm +++ b/gnu/packages/guile.scm @@ -16,7 +16,7 @@ ;;; Copyright © 2018 Eric Bavier <bavier@member.fsf.org> ;;; Copyright © 2019 Taylan Kammer <taylan.kammer@gmail.com> ;;; Copyright © 2020, 2021, 2022 Efraim Flashner <efraim@flashner.co.il> -;;; Copyright © 2021 Maxime Devos <maximedevos@telenet.be> +;;; Copyright © 2021, 2022 Maxime Devos <maximedevos@telenet.be> ;;; Copyright © 2021 Timothy Sample <samplet@ngyro.com> ;;; ;;; This file is part of GNU Guix. @@ -60,9 +60,11 @@ (define-module (gnu packages guile) #:use-module (gnu packages version-control) #:use-module (guix packages) #:use-module (guix download) + #:use-module (guix gexp) #:use-module (guix git-download) #:use-module (guix build-system gnu) #:use-module (guix build-system guile) + #:use-module (guix build-system trivial) #:use-module (guix deprecation) #:use-module (guix utils)) @@ -961,4 +963,39 @@ (define-public guile-lzma libraries, like Guile-zlib.") (license license:gpl3+))) +(define-public guile-test-driver + (package + (name "guile-test-driver") + ;; (define script-version ...) in the source code + (version "2021-01-02.05") + ;; 'search-auxiliary-file' could be used here, but that causes warnings. + (source (local-file "../../gnu/packages/aux-files/test-driver.scm")) + (build-system gnu-build-system) + (inputs (list guile-3.0)) + (arguments + (list #:phases + #~(modify-phases %standard-phases + (delete 'configure) + (delete 'check) + (delete 'install) ; no point in separating build and install + (replace 'build + (lambda _ + (define destination + (string-append #$output "/bin/test-driver.scm")) + (mkdir-p (dirname destination)) + (copy-file #$source destination) + (substitute* destination + (("/bin/sh") + ;; Reference to Guile will be patched by patch-shebangs. + "/bin/guile \\") + (("^exec guile(.*)$") "--no-auto-compile -e main -s\n")) + (chmod destination #o500)))))) + (home-page "https://www.gnu.org/software/guix") + (synopsis "Guile test driver for SRFI-64 test suites") + (description "This package, also known as @file{test-driver.scm}, provides +a Guile test driver using the SRFI-64 Scheme API for test suites. Unlike the +default test runner, its output is consistent with other test drivers used +by Automake.") + (license license:gpl3+))) + ;;; guile.scm ends here