From: Efraim Flashner <efraim@flashner.co.il>
To: guix-devel@gnu.org
Subject: [RFC]: Skipping rust crate tests by default
Date: Thu, 5 Oct 2023 15:52:46 +0300 [thread overview]
Message-ID: <ZR6xnkPLKcXqvn9H@3900XT> (raw)
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
Currently for for rust crates we build the crates, run the tests, and
then in %output we only have the license files and a repackaged version
of the source.
The build system goes:
unpack source
unpack crates
patch shebangs
patch checksums of the crates
'build
'package
'check
'install
'install is clear, it does whatever the install command is.
'package repacks the source crate, after we've done any changes to it in
the snippet and later if we've gone and patched paths to binaries or
libraries. In theory this is useful with using these crates in a
GUIX_ENVIRONMENT
'check runs the test suite, which fairly often seems to need some
massaging to skip the odd test which fails or to try to skip the doc
tests, which fail far too often.
'build sounds like it just builds the package. The first thing it does
it makes sure that all the necessary crates are included in the build
environment.
IMO the 'build phase is the most important one, it's the one that lets
us know if all the cargo-inputs and cargo-development-inputs are
correct. We don't care if rust-rand-0.6 or rust-nb-connect-1 builds, we
only care that it has the correct inputs so that when we pull it in for
an actual binary or library everything builds correctly.
I propose changing the cargo-build-system to have '#:tests? #f' by
default and then enable them for packages which have a "clear output".
It will keep the benefits of knowing we have the correct inputs without
worrying about test errors we don't care about. If it fails to build
during its own 'build phase that's actually worth looking into. It will
also cut down the amount of time the CI spends building unneeded rust
crates, and lets us see which ones are actually broken.
--
Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2023-10-05 12:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 12:52 Efraim Flashner [this message]
2023-10-05 16:38 ` [RFC]: Skipping rust crate tests by default Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-10-15 10:18 ` Josselin Poiret
2023-10-16 15:47 ` Maxim Cournoyer
2023-10-17 7:46 ` Efraim Flashner
2023-10-18 8:36 ` Efraim Flashner
2023-10-18 18:46 ` Maxim Cournoyer
2023-10-23 10:04 ` Efraim Flashner
2023-10-23 15:51 ` Maxim Cournoyer
-- strict thread matches above, loose matches on Subject: below --
2023-10-05 18:13 Nathan Dehnel
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZR6xnkPLKcXqvn9H@3900XT \
--to=efraim@flashner.co.il \
--cc=guix-devel@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).