asaaki/wargo

cargo's evil twin to work with projects in the twilight zone of WSL2

cargo's evil twin to work with projects in the twilight zone of WSL2

Motivation

The gist of the issue is the following:

You work with both Windows and WSL2. Your repositories live on a NTFS partition. Therefore the compilation performance within WSL2 will suffer, because the files have to cross the VM/file system boundaries.

Slightly more elaborate background and reasoning can be found in my article on how to speed up Rust compilation.

Solution

One approach is to copy the files into a location within WSL which is a Linux based filesystem (like ext4) and do the compilation from there. Optionally you need to copy the artifacts back to the origin.

wargo does that as a wrapper around cargo:

• copy the project into a Linux location
• run the provided cargo command
• copy back the artifacts

Currently it does this in a very simple and naive way; workspaces should work out of the box, but mostly I use single package projects. Also tweaks with the target folder may or may not work properly, the defaults are usually fine for me anyway.

There are some optional features possible, but current state is pretty complete for my personal use cases.

If you believe there is a feature missing or a tweak necessary, feel free to open a pull request or an issue.

Usage

Installation

cargo install wargo --locked

Wargo.toml (optional)

Add a basic Wargo.toml to your project if you want to configure the behaviour. The wargo wrapper does not accept any CLI arguments on its own, so a config file is the only option for now.

# Wargo.toml

# this is also the default
dest_base_dir = "~/tmp"

The file could be completely empty, but at least dest_base_dir is good to specify. Use either a location in your home dir (~) or any other absolute path, which is not an NTFS file system.

See a complete and commented example here.

Run it

# instead of `cargo` just replace it with `wargo`:
wargo check
wargo build
wargo build --release
wargo run

# alternatively also callable as a cargo subcommand `wsl`:
cargo wsl build

Safety

This crate uses #![forbid(unsafe_code)] to ensure everything is implemented in 100% Safe Rust.

License

^{Licensed under either of Apache License, Version 2.0 or MIT license at your option.}
_{Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.}

wargo's Issues

Artefact back-copy configuration

With more artefact files being copied back to the project, it might be more suitable to make this configurable.

In first iteration wargo only copied back the executable binaries, which was sufficient for my own use cases.

But this doesn't solve all cases, some people need library files for example.

---

From #110:

I just noticed that it copies way too many files back than I wanted.

I agree that it can end up copying a lot (especially the lib and rlib artifacts). I have updated the PR to include only bin, dylib and cdylib by default. It would be nice to also allow this to be overridden by a config option that explicitly specifies all of the kinds of artifacts to include (if the config option is missing, the default is used, otherwise whatever is in the config option is used). It also might make sense to provide a config setting where the user can (optionally) provide a regexp to match artifact filenames that should be copied (this would be checked after the initial artifact-kind filter has been applied). Does that sound reasonable?

Would you want to implement the option? Or shall I do it after this PR?

I could implement it, but might not get to it right away. I'm fine with taking either path, but probably the new PR can be merged in any case.

Originally posted by @edgimar in #110 (comment)

Ability to copy `cdylib` and `rlib` artifacts back to original target folder

Feature Request

The wargo tool currently only copies artifacts with a bin target kind, which means that it will not copy cdylib or rlib kinds. It would be great if it were also possible to also copy back these kinds of artifacts, either via a configuration option, or by default.