Add xtask for project workflows, but start small with only run-wasm

[ErichDonGubler]

Recommended review experience is commit-by-commit.

---

Checklist

• Run cargo clippy.
• Run RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown if applicable. N/A
• Add change to CHANGELOG.md. See simple instructions inside file.

Connections
Link to the issues addressed by this PR, or dependent PRs in other repositories

Description
Describe what problem this is solving, and how it's solved.

cargo-xtask is a convention for project workflows using a Rust crate that is separate from the main body of code. We've identified some problems that we'd like to solve with xtask¹². This PR doesn't try to address those problems specifically, but it does take on setting up xtask for further work. It also absorbs run-wasm as an easy first bit of scope.

• Add a separate binary crate called xtask that is aliased in Cargo with cargo xtask.
  • Migrate the functionality of run-wasm to xtask. Notably, this moves the some pieces of the main workspace's dependency graph to xtask.
  • Current rationale for why using a crate outside of the existing main workspace is okay.
• Hard dependency on feat: expose Args and new run_wasm_with_css_with_args rukai/cargo-run-wasm#37.

Testing
Explain how this change is tested.

• Have not yet tested that cargo xtask run-wasm yields the same running results, but it should.

Footnotes

1. See this conversation about eventually needing to manage test expectations for WebGPU CTS. ↩

2. See this pain point issue: https://github.com/gfx-rs/wgpu/issues/3680 ↩

[ErichDonGubler]

Gonna copy in some discussion from Matrix to here, since this is a better place for topical discussion.

---

@cwfitzgerald asked:

@ErichDonGubler: remind me the benefits/drawbacks of leaving the xtask out of the workspace

I responded:

Pros:

• People who don't use xtask don't ever pay the cost of compiling it.
• Toolchain-related questions for developer experience (esp. Cargo.lock, i.e., using newer versions of things) can be separate lanes from the wgpu workspace. Case in point, basically everybody using wgpu in production was compiling run-wasm whenever they ran cargo build --workspace.

Cons:

• Another compile step for people who aren't expecting it can be weird.

  • This usually isn't a problem in practice, because it's rare for xtask to need recompilation when working on the main body of wgpu's code.

• A separate xtask crate/workspace can complicate CI a bit with pressure on caching for compute-bound environments like cloud runners. Naga's compiles of xtask, for instance, would/will be a handful of minutes more until something is merged ErichDonGubler/naga#53.

  • Then again, the compiles are also unconditionally paid for in CI anyway currently, so this isn't as bad as it sounds.

[ErichDonGubler]

@cwfitzgerald: I've updated the OP with more notes explaining why we're doing this. The "further work" mentioned in the OP doesn't seem to have any issues I can link to for WebGPU CTS. Should I file one?

[cwfitzgerald]

Yeah, filling an issue about CTS test expectations sounds good, plus putting it in the testing tracking issue

[cwfitzgerald]

G2G after discussed nits

[cwfitzgerald]

Yay!

[cwfitzgerald]

Yay!