Il lun 24 giu 2024, 18:52 Daniel P. Berrangé <berra...@redhat.com> ha scritto:
> On Wed, Jun 19, 2024 at 11:13:58PM +0300, Manos Pitsidianakis wrote: > > Add options for Rust in meson_options.txt, meson.build, configure to > > prepare for adding Rust code in the followup commits. > > > > `rust` is a reserved meson name, so we have to use an alternative. > > `with_rust` was chosen. > > > > A cargo_wrapper.py script is added that is heavily based on the work of > > Marc-André Lureau from 2021. > > > > > https://patchew.org/QEMU/20210907121943.3498701-1-marcandre.lur...@redhat.com/ > > > > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> > > Signed-off-by: Manos Pitsidianakis <manos.pitsidiana...@linaro.org> > > --- > > MAINTAINERS | 5 + > > configure | 11 ++ > > meson.build | 11 ++ > > meson_options.txt | 4 + > > scripts/cargo_wrapper.py | 279 ++++++++++++++++++++++++++++++++++ > > scripts/meson-buildoptions.sh | 6 + > > 6 files changed, 316 insertions(+) > > create mode 100644 scripts/cargo_wrapper.py > > > diff --git a/configure b/configure > > index 38ee257701..6894d7c2d1 100755 > > --- a/configure > > +++ b/configure > > @@ -302,6 +302,9 @@ else > > objcc="${objcc-${cross_prefix}clang}" > > fi > > > > +with_rust="auto" > > On last week's call one of the things we discussed is the expectations > for consumers of QEMU around the usage of Rust & its optionality (or > not) long term. > > I'm of the view that to be valuable for QEMU, we need to consider > Rust to become a mandatory feature. There's a question of how quickly > we move, however, before declaring it mandatory. The longer we take > to declare it mandatory, the longer we are limiting the value we > can take from Rust. > Yes, I agree. However, considering we haven't even checked the situation with what language features are required by any idiomatic bindings vs the 1.63 version that we need to support for Debian, I think it's a bit premature to make it mandatory. As soon as the PL011 device is a reasonable example of how to write good Rust device models, however, we should switch to making it default-on, and --without-rust can go away within one or two releases. > + --with-rust-target-triple=*) with_rust_target_triple="$optarg" > As with previous posting, IMHO, this should ideally not exist. We should > honour the --cross-prefix= values, re-mapping to to Rust targets for all > the combos we know about More precisely it should be based not on the cross prefix, but on the same OS and CPU values that are detected from cpp symbols and used for the meson cross file. I have already made a rough list of differences between these and the Rust target triples, but I haven't yet turned them to code. It would however be the first patch I send after these are in a good shape for inclusion. The priority right now should be to investigate the build tree workspace design that I sketched last week in my reply to Richard. Once that can be considered a stable build system integration, further improvements can be done in tree. --with-rust-target-triple should only be needed > as a workaround for where we might have missed a mapping. > Agreed. Paolo
