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