Il mer 19 giu 2024, 18:54 Daniel P. Berrangé <berra...@redhat.com> ha scritto:
> > 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 > eg > > aarch64-softmmu-hw/ > Cargo.toml # generated by meson.build (*) > src/ > pl011/ # symlink to srctree/hw/p1011/ > > > 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 :| > >
