Refactor espup

[SergioGasquez]

As discussed in #154 we are going for a minimal approach, hence I refactored what we have, and here is the resulting behavior:

• espup install installs under $RUSTUP_HOME/toolchain/<toolchain_name>:
  • Xtensa Rust (if any Xtensa target is provided)
  • Nightly Rust (if any RISC-V target is provided)
  • Xtensa LLVM clang
  • GCC for the provided targets (to be served as linker in no_std apps)
    • This would be removed once LLD can be used
• espup update will update the Xtensa rust under $RUSTUP_HOME/toolchain/<toolchain_name>:
  • It will use latest if no -v/xtensa_version is provided
  • If the semver of the version trying to install is the same as the version installed it won't install it but it will print a warning message (as we use an extended version of semver and they might be differences)
• espup uninstall will delete $RUSTUP_HOME/toolchain/<toolchain_name>

Other changes:

• Added an option (-s/--std) that avoids installing GCC (it will be installed by esp-idf-sys)
• You can modify the Xtensa toolchain name (defaults to esp) by using the -a/name option
• [Windows]: Environment variables are automatically injected into your system when installing and cleared when uninstalling
• Removed the config file
• Dependencies cleanup
• Removed -x/--llvm-version option as we only supported one version.
• By default, only libs or LLVM are installed, you can opt-in to install the whole llvm with -e/--extended-llvm
• Other minor improvements like error naming, logs updated, running some commands in parallel...
• cd.yml now also publishes to crates.io

[bjoernQ]

Wow that's a lot. Haven't spotted any obvious things when looking at the code

[JurajSadel]

LGTM!

[jessebraham]

Looks good!

[SergioGasquez]

Few important things to note, once we merge it and release a new version:

• We will need to update instructions on the book
• The Xtensa toolchain action also requires an update since the --profile-minimal option is gone (we use it by default)

[MabezDev]

Looks good to me :)

[jessebraham]

• The Xtensa toolchain action also requires an update since the --profile-minimal option is gone (we use it by default)

This is a bit problematic, given that any deployments using the current version of the toolchain will start failing once this is published.

[bjoernQ]

* The Xtensa toolchain action also requires an update since the `--profile-minimal` option is gone (we use it by default)

This is a bit problematic, given that any deployments using the current version of the toolchain will start failing once this is published.

Will it pick-up the new version automatically?
Maybe we could re-add that option and print a warning that this is deprecated and a no-op now? I know that is ugly

[SergioGasquez]

This is a bit problematic, given that any deployments using the current version of the toolchain will start failing once this is published.

If they are pinned to 1.5.0 it will. Shall we keep the flag even though it does nothing?

[jessebraham]

I think for the time being maybe just adding a deprecation warning and having it not do anything as @bjoernQ mentioned is fine. I just don't want to keep breaking CI and forcing users (and us) to update over and over, you know?

[SergioGasquez]

Forget what I've said about xtensa-toolchain, we are actually not using that flag, even though at some point we did but it looks like when removing the install.sh I forgot to add it, so xtensa-toolchain would work with no changes required.

Sorry for the noise.

Still, tomorrow I would tag the release as pre-release and use a fork of the action to verify that its working properly.

[SergioGasquez]

Merged the PR, created a pre-release, and tested the action in different repos:

• esp-hal
• esp-flasher-stub

Ran the CI 5 times in each repo with no issues.
I also had to merge #188 as it was causing some transient errors, as we had in the past (#137).

I'll proceed to mark it as latest release and publish it to crates.io