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.
If we consider Rust to be an optional feature, then this largely
precludes re-writing existing C code in Rust, as we would be
forced to either remove existing features from users, or maintain
parallel impls in both C & Rust. Neither of these are desirable
situations.
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.
If we want to make Rust mandatory, then we should set the user
expectations to reflect this from the start.
IOW, with_rust="enabled" should be the default, and require an
explicit --disable-rust to opt-out on a very time limited
basis. Any use of --disable-rust ought to print a warning at
the end of configure, and solicit feedback:
WARNING: Building without Rust is deprecated. QEMU intends
WARNING: to make Rust a mandatory build dependency in the
WARNING: 10.0.0 release.
WARNING:
WARNING: If you have concerns about this requirement
WARNING: please contact qemu-devel@nongnu.org
I illustrated '10.0.0' on the assumption that we add Rust
support in 9.1.0, and thus have 2 releases where it is
optional to align with our deprecation policy. Even though
we don't usually apply our deprecation policy to build
dependencies, this is a significant unique situation so
IMHO worth doing.
> +with_rust_target_triple=""
> +
> ar="${AR-${cross_prefix}ar}"
> as="${AS-${cross_prefix}as}"
> ccas="${CCAS-$cc}"
> @@ -760,6 +763,12 @@ for opt do
> ;;
> --gdb=*) gdb_bin="$optarg"
> ;;
> + --enable-with-rust) with_rust=enabled
> + ;;
> + --disable-with-rust) with_rust=disabled
> + ;;
--enable-with-XXX / --disable-with-XXX is pretty unsual naming.
Normally you'd see either --enable-XXX or --with-XXX and their
corresponding --disable-XXX or --without-XXX.
> + --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. --with-rust-target-triple should only be needed
as a workaround for where we might have missed a mapping.
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 :|
