all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxime Devos <maximedevos@telenet.be>
Cc: 58365@debbugs.gnu.org
Subject: [bug#58365] [PATCH 0/6] Support #:tests? in guile-build-system
Date: Tue, 18 Oct 2022 17:44:55 +0200	[thread overview]
Message-ID: <878rldkufc.fsf@gnu.org> (raw)
In-Reply-To: <d3cb4d96-e135-a8d5-8600-7d5f4ec7a7c5@telenet.be> (Maxime Devos's message of "Tue, 18 Oct 2022 15:30:56 +0200")

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’.




  reply	other threads:[~2022-10-18 15:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 20:47 [bug#58365] [PATCH 0/6] Support #:tests? in guile-build-system Maxime Devos
2022-10-07 20:53 ` [bug#58365] [PATCH 1/6] gnu: Add guile-test-driver Maxime Devos
2022-10-07 20:53   ` [bug#58365] [PATCH 2/6] build-system/guile: Run SRFI-64 tests Maxime Devos
2022-10-07 20:53   ` [bug#58365] [PATCH 3/6] guile-ffi-fftw: Respect #:tests? Maxime Devos
2022-10-07 20:53   ` [bug#58365] [PATCH 4/6] guile-ffi-fftw: Modernise style Maxime Devos
2022-10-07 20:53   ` [bug#58365] [PATCH 5/6] guile-ffi-fftw: Update to new Guile version Maxime Devos
2022-10-07 20:53   ` [bug#58365] [PATCH 6/6] guile-ac-d-bus: Don't duplicate 'check' phase Maxime Devos
2022-10-18 12:36   ` [bug#58365] [PATCH 0/6] Support #:tests? in guile-build-system Ludovic Courtès
2022-10-18 13:30     ` Maxime Devos
2022-10-18 15:44       ` Ludovic Courtès [this message]
2023-11-20  0:34         ` Maxime Devos
2023-11-20  0:41           ` Maxime Devos
2023-12-03  9:17           ` Efraim Flashner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rldkufc.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=58365@debbugs.gnu.org \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.