Include the UEFI app in the workspace

[andrisaar]

Right now the UEFI app under experimental/uefi is excluded from workspace in the root Cargo.toml file, as we need a custom .cargo/config.toml file for the UEFI app.

Ideally, we'd want to get rid of the .cargo/config.toml file there, and (a) fold things into the root .cargo/config.toml file and/or (b) move things to the Cargo.toml file of the UEFI app.

Unfortunately we can't do that yet. Looking at what we have in the .cargo/config.toml file and what we can do about those fields:

• target could move to Cargo.toml using https://doc.rust-lang.org/cargo/reference/unstable.html#per-package-target
• the runner stanzas could likely be moved to the root .cargo/config.toml with relative ease
• build-std and build-std-features needs https://github.com/rust-lang/cargo/issues/9451 before we can do anything about them.

[jul-sh]

For build-std and build-std-features, could we pass these values as command line flags instead?

Eg -Zbuild-std-features=compiler-builtins-mem -Zbuild-std=core,alloc. It seems like that should work, though it may conflict with the existing workspace config file.

[andrisaar]

That won't help when you're running, say, cargo doc in the root directory as xtask does. I assume we don't want to rebuild std for every crate, just the limited UEFI one(s).

[jul-sh]

Yeah it would require some (potentially unwieldy) changes to xtask. The upside of using xtask though is that that's feasible. Eg it'd work quite nicely for running examples etc

[mariaschett]

Maybe relevant: I tried using the per-package-target before (#2468 ), but didn't get it to work.

[andrisaar]

Maybe relevant: I tried using the per-package-target before (#2468 ), but didn't get it to work.

It looks like your main issue was that the tests got also compiled for wasm. That's the case here as well (tests get compiled for uefi), but as we specify a loder (qemu) cargo test will be able to execute the tests just fine.

[jul-sh]

tested my earlier idea of adapting cargo (with custom runners) a bit, but don't think it's worth it. Ref: #2733. If the workspaces PR doesn't progress to unblock this, we could alternatively consider using cargo vendor to share deps, ala what Mozilla did: https://github.com/rust-lang/cargo/issues/5332#issuecomment-380088273

The nice thing about the workspace free approach is that we can still have a shared config file that sets general config, but unlike with workspaces nested cargo configs are also read (and can set UEFI specific flags).

[conradgrobler]

The UEFI version has been deleted.