[bug#58365] [PATCH 0/6] Support #:tests? in guile-build-system

[Maxime Devos]

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

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature