qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v4 2/7] rust: add bindgen step as a meson dependency


From: Peter Maydell
Subject: Re: [RFC PATCH v4 2/7] rust: add bindgen step as a meson dependency
Date: Tue, 9 Jul 2024 13:08:57 +0100

On Tue, 9 Jul 2024 at 11:53, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
> > +msrv = {
> > +  'rustc': '1.77.2',
> > +  'cargo': '1.77.2',
> > +  'bindgen': '0.69.4',
> > +}
>
> This is still pretty bleeding edge (it even tripped up on the
> .cargo/bin/cargo I have installed). This needs to be set to the
> baseline which from:
>
>   https://wiki.qemu.org/RustInQemu/2022
>
> Looks to be 1.24.0 for rustc and I guess even lower for cargo (Debian
> says 0.66.0). While it might make sense to delay merging if we are
> waiting for one distro to produce a new LTS we shouldn't be needing
> rustup by default.

I suspect that some of the older distro releases in that chart
have already fallen off the end of our supported-platforms set,
so the minimum is probably newer than 1.24.0 now.

My take on this one is that (at some point, not necessarily
right now) we want to look at:

 * what is the actual baseline requirement? We definitely want
   to support "using rustup on an older system" (should be no
   problem) and "current distro building QEMU using the distro's
   rust", I assume. It would certainly be nice to have "building
   QEMU on the older-but-still-in-our-support-list distro releases
   with that distro's rust", but this probably implies not just
   a minimum rust version but also a limited set of crates.
   I think (but forget the details) that some of what we've done
   with Python where we accept that the older-but-still-supported
   distro will end up taking the "download at build time" path
   in the build system might apply also for Rust.
 * what, on the Rust side, is the version requirement? Presumably
   there's some features that are pretty much "we really need
   this and can't do without it" and some which are "this would
   be pretty awkward not to have but if we have to we can implement
   some kind of fallback/alternative with a TODO note to come
   back and clean up when our baseline moves forwards".

At that point we have more information to figure out what
if any tradeoff we want to make.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]