Re: [PULL 00/12] Rust initial PoC + meson changes for 2024-10-07

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Oct 07, 2024 at 01:26:52PM +0200, Paolo Bonzini wrote:
> On Mon, Oct 7, 2024 at 1:11 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > The current dockerfiles don't include rust, and I see nothing
> > here updating them to add rust, so how is any of this getting
> > test coverage ?
> >
> > Even though this has Rust disabled by default, I would still
> > consider CI enablement to be a pre-requsite for merging even
> > basic Rust support.
> 
> I agree in general, but there's already a lot of work that can be
> parallelized and the idea of someone managing Rust-related patches
> out-of-tree was discarded. So this seemed to be the only way to
> proceed.
> 
> Right now only Fedora 39 and 40 (with updates) are able to compile
> QEMU with Rust enabled. Full CI enablement requires further work to
> reduce the minimum supported version of the compiler, after which
> rustc can be added to the libvirt-ci inputs and to the Dockerfiles.

Full CI enablement isn't a requirement until we want to turn on
Rust by default. It would be sufficient to have a single job in
CI using Fedora 40 that passes '--enable-rust' to demonstrate that
this at least working on one platform we expect.

> Adding a CI job that uses nightly rust (via rustup) is high on my
> priority list, but first of all I wanted to integrate clippy (because
> the main point of having a job with nightly rust is to have a heads-up
> on future clippy warnings). That said, I'm also not sure how one would
> go adding rustup to a container generated by lcitool (for example
> should I add a new dockerfile that is _based_ on one that already
> exists? would that change when Rust/rustc is added to that
> dockerfile?).

Having layered dockerfiles is something we try to aviod these days,
since each layer turns into another job dependancy in the CI
pipeline, expanding the number of stages.

If the job is merely to validate nightly clippy do we even need
any of the rest of the QEMU build deps present ?  Can we not just
use a generic pre-existing Rust container and only run clippy
in it.

If we want to actually build with the cutting edge, then I'd say
it is sufficient to have a container based on Fedora rawhide, since
that gives a heads up on what's soon to be impacting the next stable
distro release, upto 6 months ahead of time - we don't need to be
watching& debugging stuff that hasn't even been released by Rust
yet IMHO.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|