Add section to "Working in WSL2" about natively compiling

[Minhaul]

Background

I'd like to propose a section be added to the "Working in WSL2" page about natively compiling and running on windows through WSL2 (rather than cross compiling, or natively compiling not through a WSL2 development environment).

This setup involves being able to run a command in your WSL2 terminal that will invoke cargo in your native windows environment without anything visibly happening outside of your WSL2 terminal. I've noticed that this setup, in comparison to cross compiling to windows from within WSL2 ubuntu:

• has faster iterative compile times (with lld as the linker for both, no dynamic linking)
• has significantly smaller debug executables and startup time of those executables (~1GB and 30s to startup when cross compiled compared to ~50MB and effectively instantaneous startup when compiled natively)
• is so much less finicky (I couldn't figure out how to get dynamic linking to work when cross compiling, but it "just works" with this setup)
• still allows you to (mostly) pretend that windows terminal environments don't exist :)

Setup

• Install rust natively on windows from rustup.rs.
• I'd recommend changing your cargo build.target-dir on windows so that you aren't mixing your WSL2 and windows filesystems. I changed my global cargo config on windows (found at C:\Users\NAME\.cargo\config.toml) to something like this:

[build]
target-dir = "C:\\Users\\NAME\\cargo_builds\\target"

• Create a script to call from within WSL2 to run cargo natively. What mine looks like:

#/bin/sh
shift # drop first arg
powershell.exe /c "cargo $@"

Note that I'm using powershell.exe instead of cmd.exe because cmd.exe doesn't understand network drive paths and that's how the WSL2 filesystem is mounted.
Also, I'd recommend creating this as a cargo custom command for ease of use. My script is named cargo-win and is in a directory on my linux path. If you don't create it as a cargo custom command, you'll want to remove the shift line so you don't drop actually useful args.

If all that's been followed in the same way I did it, you'll then have a cargo win command that will just run any cargo command from your WSL2 terminal and have it really be running in your native windows environment transparently (e.g. cargo win run, cargo win build --release --no-default-features, etc.). This still shows all cargo output as well as logs for your game executable in the WSL2 terminal window that you invoked cargo win ... in.

Personal Note

I spent a lot of time trying to figure out how to get cross compilation working to a productively functional level, getting frustrated with all the strange bits that just didn't really work well, and then spent more time trying to get a native solution like what I've described above to work all while being able to not leave my WSL2 development environment. I would have really appreciated this knowledge existing in this book when I was getting started, and I hope that you agree that it'd be a worthwhile addition in whatever form you deem most relevant and helpful.

I'm happy to answer any questions you might have about any of this.

[Multirious]

I have been cross compiling for awhile and the startup time when launching for the first time after build does take a very long time. But launching for the second time for the same build is instantaneous. I have no clue why that is the case.

[Minhaul]

I experienced the same when I was cross compiling. I suspect it's windows caching the file in RAM which causes subsequent launches to be effectively instantaneous. Not very helpful when you're iterating quickly though lol.

[Multirious]

How should Rust-Analyzer be configured?

I've setup a project-scoped .cargo/config.toml in WSL that has the config:

[build]
target-dir = "C:\\Users\\USER\\bevy_builds"

My WSL Rust-Analyzer just straight up create a directory in my project with the name 'C:\Users\USER\bevy_builds'

There's also this issue. I have my project directory that stays in C:\... and symlinked to my WSL which causes cargo config issue. Seems like I may need to restructure my stuff.

[Minhaul]

Your .cargo/config.toml that sets the build.target_dir needs to be on the windows side at C:\Users\NAME\.cargo\config.toml, not the WSL2 side.

Also, my setup assumes your project lives in WSL2's linux filesystem, not your windows filesystem. I'm not sure how it would behave with the setup you've described where your project lives in your windows filesystem with it symlinked to your WSL2 linux filesystem.

With my setup, rust-analyzer has needed no extra configuration from the norm. It does native linux builds for checking and stores that in my project dir in target/.

[Multirious]

I've restructured my projects directory for a bit. Having 2 builds for both Windows and Linux will probably took a bit of space but worth the trade-off. Anyways this works beautifully. Thanks for the tutorial!