From: Maxime Devos <maximedevos@telenet.be>
To: Guix-devel <guix-devel@gnu.org>
Cc: Hartmut Goebel <h.goebel@crazy-compilers.com>
Subject: antioxidant update: librsvg builds, and other things (core-updates)
Date: Sat, 27 Aug 2022 12:54:30 +0200 [thread overview]
Message-ID: <1a94a3b6-4798-fb44-013c-4452931c29d4@telenet.be> (raw)
[-- Attachment #1.1.1.1: Type: text/plain, Size: 3940 bytes --]
Some updates:
* core-updates is now targeted instead of master (because the librsvg
on core-updates has a less complicated build system and hence easier
to support with antioxidant)
* librsvg now builds. It's about 3 times larger than the
cargo-build-system librsvg (at least, the librsvg from master,
didn't compare against core-updates yet because there was no
substitute available), so perhaps some compilation flags need to be
changed.
* According to ci.guix.gnu.org, antioxidation is at 90%, but some of
the 'failures' are because of cancelled builds in dependencies, the
real number should be higher. Maybe 'Restart all builds' would be
correct that, though I don't know if that wouldn't restart too much
builds (including builds that succeeded).
* Running tests is supported, #:tests? and #:parallel-tests? is
respected, there is an option to skip some tests (using
#:test-options). As antioxidant doesn't do #:skip-build? #t, I
expect more packages to be tested with antioxidant than with
cargo-build-system.
There are some test failure, things like "tries accessing the
network" are simply skipped. Sometimes it is assuming incorrect
things about the build environment such assuming that stderr is a
terminal, those are simply skipped. Sometimes test files are removed
from the tarballs uploaded at crates.io, this appears to be
intentional, there is a project to remove all such 'bloat',
disregarding the value of tests -- for those packages we will have
to switch to git checkouts, but for now I simply disabled tests there.
I've also found some time bombs (e.g. rust-rustls appears to have a
certificate expiration problem), there tests are disabled too.
There were also some genuine test failures, some of them have been
reported upstream but not all of them yet.
* antioxidant now has some defenses against bundling -- it detects if
the feature "bundle", "vendor" or "vendored" is implicitly enabled
and if so, bails out unless they were explicitly added to the
package definition.
* I don't know if I mentioned it previously, but antioxidant now
supports some 'unstable' rust code even when using 'stable' Rust
compilers, by setting RUSTC_BOOTSTRAP=1. It's 'not supposed to be
used', but if it's good enough for the Rust compiler, then it should
be good enough for other software too, I'd think.
Some questions:
* Some Rust crates have 'examples' and 'benchmarks' that can be
compiled and installed. I could teach antioxidant to compile and
install them, though it appears to provide very little value at cost
of more compile time and a greater closure size (more binaries, more
dependencies and wasn't there some bug with grafts whose fix causes
outputs to be substituted that ended up unused? Though hopefully
someone could figure out a better fix ...)
* Due to how regularised the Rust build system is, it's feasible to
compile tests even when cross-compiling (*), so cross-compiled could
run the cross-compiled tests on the system they are cross-compiling
for after the cross-compilation to verify their cross-compiled software.
Currently, tests are only compiled and installed when #:tests? #true
which is only the case when compiling natively(*), but with some
work I could separate building tests from running tests and build
tests by default when cross-compiling. Downside: tests have to be
installed in an output, which increases the closure size.
(Currently tests are installed in an output, but I could change that
to the working directory).
(*) antioxidant doesn't support cross-compilation yet, but in the past
I've tried out cross-compiling the standard library and it seemed to
work, though it wasn't completed.
[-- Attachment #1.1.1.2: Type: text/html, Size: 4613 bytes --]
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
next reply other threads:[~2022-08-27 10:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-27 10:54 Maxime Devos [this message]
2022-08-27 19:54 ` antioxidant update: librsvg builds, and other things (core-updates) Liliana Marie Prikler
2022-08-27 20:01 ` Maxime Devos
2022-08-27 22:04 ` Liliana Marie Prikler
2022-08-28 9:38 ` Maxime Devos
2022-09-01 10:40 ` Hartmut Goebel
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=1a94a3b6-4798-fb44-013c-4452931c29d4@telenet.be \
--to=maximedevos@telenet.be \
--cc=guix-devel@gnu.org \
--cc=h.goebel@crazy-compilers.com \
/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).