Single Cargo workspace for the entire repository

[tiziano88]

We currently have at least 3 Cargo workspaces, and if we keep the current structure we may need to add at least an additional one for things like #533 .

We should consider having a single workspace rooted in the repository root, which will allow us to maintain a single version of our all dependencies. In this model, every single crate will be nested in the global workspace.

If anyone thinks this may be problematic, please follow up here.

[daviddrysdale]

I slightly wonder whether we'll end up needing one workspace for each environment that Rust code runs in – are there any workspace-wide settings that might not work when they're shared between a build-for-Wasm-with-minimal-std and a build-for-x86-with-full-libraries?

[tiziano88]

AFAICT there are no workspace-wide settings, or if there are we don't seem to be using them anyways.

My understanding is that crates in a workspace would share their Cargo.lock file, cache, and output (target) folder. Under the target folder there are already subfolders for each target architecture / platform, so I think it should all be fine.

[tiziano88]

@wildarch do you happen to know if there is any downside in coalescing all our crate in a single top-level Cargo workspace?

My understanding is that we should still be able to individually publish individual crates, and people depending on those would only pull the minimum amount of dependencies (as opposed to all of the workspace dependencies). Anyone let me know if I am missing something though.

[wildarch]

You can definitely publish individual crates in your workspace, there should be no issue there. Like @daviddrysdale I'm a bit skeptical about having code for multiple different targets in one workspace, is there a way to specify for what platform certain crates should be built?

[wildarch]

Looks like that is not yet possible. This would mean that if you make a single workspace you probably couldn't just cargo build it in one go 😓

[ipetr0v]

I think we might have 2 workspaces: examples and oak.
Later, when we will decouple examples in a separate repository, there will be only one workspace remaining in the oak repo.

[tiziano88]

Sure, later when we decouple the SDK from the runtime, it may also make sense to split those, but I still think for now we may be better off with a single workspace. Splitting things off is just a matter of re-creating the workspace file, all the rest is taken care of by cargo. I think we should go ahead with this, I don't expect it will be a large change.