feature: Better Windows Support

[KartikSoneji]

Windows Fixes

• fixes anchor init
• fixes anchor build
  • fixes anchor fails windows - I don't want to use WSL. No other solution? #1992
  • fixes Anchor fails on Windows #1577
  • should fix Anchor build >> thread 'main' panicked at 'Not in workspace.' #1351
  • fixes failed to read package metadata on Windows if the project is on different drive location #2973
• works around cargo build-sbf Can't get home directory path: environment variable not found solana-labs/solana#35558
  and Can't get home directory path: environment variable not found #1337
  • fixed in fix: build-sbf Home Directory Error on Windows anza-xyz/agave#3597 but workaround needed till unpatched versions are supported
• the package manager installation command on windows needs to be run with the .cmd suffix (like npm.cmd)
  this PR adds a PackageManager::executable_name() method to return the correct name based on the OS
• if the invocation of the package installation command fails (the specified manager is not installed, or not present on the path) then anchor didn't fallback to npm but instead exits with the error program not found
  • fixes anchor init hello-anchor throwing error #1805

Release Improvements

Provides prebuilt binaries for anchor and avm

• for all platforms: Windows, MacOS Intel, MacOS ARM, Linux
• commits to main publish the binaries as artifacts
• tagging a commit creates a GitHub release

TODO: The avm install script still needs to be changed to use the prebuilt binaries instead of building from source.

[vercel]

@KartikSoneji is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

[acheroncrypto]

Thanks! As we've discussed in Discord, please only make the changes necessary to support Windows (no CI changes).

There are also so many more commands that the CLI makes use of — are you sure these are all the changes we need?

[KartikSoneji]

I'll move the CI commits to a separate branch.
As for the commands, I wanted to start with the most used ones.
Is there a test suite I can run to check the rest of the commands?
Or a list?

[acheroncrypto]

As for the commands, I wanted to start with the most used ones.
Is there a test suite I can run to check the rest of the commands?
Or a list?

You can find all of them by searching for Command::new usage in the CLI codebase.

However, it seems strange to me that Rust doesn't already take care of making commands work by their name on Windows by default. Do all CLIs that want to support Windows have to run <name>.cmd?

In any case, we could just implement a std::process::Command wrapper that does this automatically rather than having to change every command individually.

[KartikSoneji]

However, it seems strange to me that Rust doesn't already take care of making commands work by their name on Windows by default. Do all CLIs that want to support Windows have to run .cmd?

Ah so this is actually a quirk of node and node based executables.
Node commands like npm, yarn etc are written in JS and need to be run in a node runtime.
To abstract away this implementation detail, node commands user wrapper scripts:

• <command> for unix (eg npm)
• <command>.cmd for Windows cmd (eg npm.cmd)

Running npm in the shell on Windows calls the correct npm.cmd script because the PATHEXT variable contains .BAT

But std::process::Command doesn't take PATHEXT into consideration so fails to find the correct file to call.