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 12:47:08PM +0100, Daniel P. Berrangé wrote:
> 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.

I forgot to say that QEMU's 'refresh' script can customize the
dockerfiles from lcitool with an arbitrary amount of trailing
text - see the 'debian12_extras' for example.

> 
> 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 :|