Hi there :)
On 11/06/2024 12:58, Manos Pitsidianakis wrote:
On Tue, 11 Jun 2024 13:57, "Daniel P. Berrangé" <berra...@redhat.com>
wrote:
On Mon, Jun 10, 2024 at 11:29:36PM +0300, Manos Pitsidianakis wrote:
On Mon, 10 Jun 2024 22:37, Pierrick Bouvier
<pierrick.bouv...@linaro.org> wrote:
> Hello Manos,
> > On 6/10/24 11:22, Manos Pitsidianakis wrote:
> > Hello everyone,
> > > > This is an early draft of my work on implementing a very
simple device,
> > in this case the ARM PL011 (which in C code resides in
hw/char/pl011.c
> > and is used in hw/arm/virt.c).
> > > > The device is functional, with copied logic from the C code
but with
> > effort not to make a direct C to Rust translation. In other
words, do
> > not write Rust as a C developer would.
> > > > That goal is not complete but a best-effort case. To give a
specific
> > example, register values are typed but interrupt bit flags are
not (but
> > could be). I will leave such minutiae for later iterations.
snip
> Maybe it could be better if build.rs file was *not* needed for new
> devices/folders, and could be abstracted as a detail of the python
> wrapper script instead of something that should be committed.
That'd mean you cannot work on the rust files with a LanguageServer, you
cannot run cargo build or cargo check or cargo clippy, etc. That's why I
left the alternative choice of including a manually generated
bindings file
(generated.rs.inc)
I would not expect QEMU developers to be running 'cargo <anything>'
directly at all.
QEMU's build system is 'meson' + 'ninja' with a 'configure' + 'make'
convenience facade.
Any use of 'cargo' would be an internal impl detail of meson rules
for building rust code, and developers should still exclusively work
with 'make' or 'ninja' to run builds & tests.
No, that's not true. If I wrote the pl011 device with this workflow I'd
just waste time using meson. Part of the development is making sure the
library type checks, compiles, using cargo to run style formatting, to
check for lints, perhaps run tests. Doing this only through meson is an
unnecessary complication.
My favorite tool for Rust development is rust-analyzer, which works very
well with cargo-based projects. Making it work with meson is just a
matter of pointing rust-analyzer to the rust-project.json file generated
by meson at configuration time (just like compile_commands.json).
Unfortunately, rust-analyzer also relies on cargo for doing its check. I
was able to override that with ninja, but it requires `meson setup` with
`RUSTFLAGS="--emit=metadata --error-format=json"`. That makes
rust-analyzer happy, but compilation output is not readable anymore
being json-like.
I ended up working with 2 build folders, one for me, one for
rust-analyzer. So, yeah, it complicates a bit.
To compile and run QEMU with a rust component, sure, you'd use meson.
Cheers,
Antonio
