> build/
> rust/
> .cargo/
> config.toml # generated by configure or meson.build
> Cargo.toml # workspace generated by configure or meson.build
> Cargo.lock # can be either linked to srctree or generated
> qemu/ # symlink to srctree/rust/qemu
> aarch64-softmmu-hw/
> Cargo.toml # generated by meson.build (*)
> src/ # symlink to srctree/rust/hw/
> i386-softmmu-hw/
> Cargo.toml # generated by meson.build
> src/ # symlink to srctree/rust/hw/
> generated/ # files generated by rust/generated/meson.build
If we're generating a build tree to invoke cargo on, can we then
avoid creating a completely separate dir hierarchy in the source
tree rooted at /rust, and just have rust source within our existing
hierarchy.
Maybe... I hadn't even considered the possibility of having a single cargo invocation (and thus a cargo workspace in the build tree) until Richard pointed out the duplication in configuration files.
I suppose you could just link rust/aarch64-softmmu-hw to srctree/hw, and have a srctree/hw/
lib.rs file in there to prime the search for submodules.
I think the resulting hierarchy would feel a little foreign though. Without seeing the code I can't judge but my impression is that, if we wanted to go that way, I would also move all C code under src/. Perhaps we can consider such a unification later, once we have more experience, but for now keep Rust and C code separate?
Paolo