Add windows-toolchain input

[MSP-Greg]

Adds a windows-toolchain input.

1. Only affects Windows Rubies.
2. Current PR allows only one optional setting, which is none.  It installs the selected Ruby and adds it to PATH. No build tools are installed/activated. Hence, no extension gems can be compiled/installed via bundler.

Closes #562

[k0kubun]

Thanks!

[eregon]

The general functionality looks fine but I don't understand in which cases it has effect or not, and the input name seems too confusing.

[eregon]

The name of the option and this description is confusing me.
Is the effect whether to install MSYS2 or not? If so msys2: true/false seems clearer.
Or maybe a more general term like setup-toolchain: true/false (or maybe something with windows in the name since it only applies on Windows).

Also what does this do for RubyInstaller2 builds (both release and head), is the native toolchain there always provided and the option has no effect? So then the option only affects the mswin & ucrt builds?

[MSP-Greg]

Maybe a better name would be win-platform-override?

As mentioned, I'd like to add additional values like mingw, ucrt, and mswin, but I don't have time to write those now.

The input allows one to override the installation of build tools and packages, which currently is based on the installed/activated Ruby. So, one could install/activate a Windows ucrt Ruby, but install mswin tools and packages.

For now, the only available value is none, which doesn't install any build tools or packages.

What @k0kubun has asked for is the ability to install/activate a Ruby specified by ruby-version, but nothing else.

If you look at the current ruby/ruby CI build scripts, they install all the build tools and packages. They'd prefer to do so, as it allows ruby/ruby committers to make changes without affecting anything here.

The main application of this input would be building Ruby. For instance, in ruby-loco, I use this to install build tools/packages. But, that means I have to activate a Ruby that matches the platform of the Ruby being built. That's a 'dependency' that I'd prefer not to have.

Almost all users of this action should not use the new input.

[eregon]

Maybe a better name would be win-platform-override?

I feel weird about using the term platform for this.
My understanding of platform (and RUBY_PLATFORM) is it's basically $ARCH-$OS[$OSVERSION].
It's true that on Windows the values of RUBY_PLATFORM are more varied: x64-mingw-ucrt, x64-mingw32, x64-mswin64_140.

But RUBY_PLATFORM at least to me sounds like "the platform on which that ruby was built". And there is no way to override or change that for an existing binary.

I think toolchain seems a better term for this, at least that's the term I know on Linux & macOS for "which C compiler, libc, etc is available/in PATH" (e.g. a LLVM 15.0.7 toolchain (which e.g. might be configured to use libc++ instead libstdc++), a gcc 12.3.1 toolchain using glibc).
BTW there is also musl toolchains vs glibc toolchains on Linux (more precisely, toolchains can use one of these libc's), that seems very similar to the ucrt/mingw/mswin situation.

I would say for instance that there is toolchain to build Ruby and a toolchain to build Ruby native extensions and they don't have to be the same.

@MSP-Greg Do you think the name windows-toolchain: default/none (and later adding mingw/ucrt/mswin if usefl) would make sense? i.e. is "toolchain" a meaningful term on Windows too and appropriate for this?

Or maybe devkit as the input name? WDYT?

---

I have tried looking up some of the websites to see if they talk about toolchain or something that sounds like it.
It seems to match:

https://rubyinstaller.org/downloads/ names it Devkit (I also found the term "development environment" used).
Also from that page:

With Development Kit?
RubyInstaller uses the MSYS2 toolchain as its development kit.
...
[...] with the rich UNIX toolset of MSYS2 and the large repository of MINGW libraries.

devkit could also be a good name I think.
https://en.wikipedia.org/wiki/Software_development_kit fits rather well.

https://www.msys2.org/

MSYS2 is a collection of tools and libraries ...

Sounds like a toolchain to me.

https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-170

From Visual Studio .NET through Visual Studio 2013, each major release of the C++ compiler and tools has included a new, standalone version of the Microsoft C Runtime (CRT) library.

So one way to see that is MSVC is a toolchain and somewhat part of that toolchain (or a dependency of it) is the CRT (basically the libc).

https://gnutoolchains.com/ (a random website I found while googling) seems to use the term toolchain for Windows too.

[MSP-Greg]

Changed input name to win-ruby-platform-override. Also updated the comments in action.yml.

[MSP-Greg]

I updated the test added to test.yml. I originally used a PowerShell script, but that's unclear for many people. Changed to a ruby command, and checked it in my fork (see https://github.com/MSP-Greg/setup-ruby/actions/runs/7560951646)

[MSP-Greg]

Although I don't recall people using Windows self-hosted runners, they may prefer to use win-ruby-platform-override: none if they have all 'build related files' pre-installed on their images...

[eregon]

It would be great to describe what 'default' does here

[eregon]

Suggested change

	run: ruby -e "File.exist?('C:/msys64/mingw64/bin/gcc.exe') && exit!(1)"
	run: ruby -e "abort if File.exist?('C:/msys64/mingw64/bin/gcc.exe')"

[MSP-Greg]

Never noticed abort, I'll change.

[eregon]

I understand the functionality well know, thanks for your comments.
The main thing left is finding a good name for this input.

[MSP-Greg]

Do you think the name windows-toolchain: default/none (and later adding mingw/ucrt/mswin if usefl) would make sense? i.e. is "toolchain" a meaningful term on Windows too and appropriate for this?

That's fine by me, could also be windows-toolchain-override, which makes clear that it's changing something.

Which would you prefer, windows-toolchain or windows-toolchain-override?

EDIT:

Re using the word devkit, that's always been about MSYS2 toolchains, some people might not even be aware of mswin...

I understand the functionality well now, thanks for your comments.

Glad that helped. Apologies in advance for Windows explanations. I wrote plenty of code on MSFT DOS, sometimes my Windows explanations are too brief, sometimes too thorough...

[eregon]

Let's go with windows-toolchain. I think the "override" part is implied by not using the input's default value.

[MSP-Greg]

Before I spin up a gazillion jobs, how's the below for action.yml?

  windows-toolchain:
    description: |
      This only affects Windows runners.
      The default setting ('default') installs a toolchain based on the installed/activated Ruby.
      This allows Windows platform setup to override the default toolchain setup.
      At present, the only allowed setting is 'none', which only adds Ruby to PATH.
      No build tools are installed, nor are any ENV setting changed to activate them.
    default: 'default'

[eregon]

Sounds good. I'm thinking to take this opportunity to document a bit better what the default does:

  windows-toolchain:
    description: |
      This input allows to override the default toolchain setup on Windows.
      The default setting ('default') installs a toolchain based on the selected Ruby.
      Specifically it installs MSYS2 if not already there and installs mingw/ucrt/mswin build tools.
      It also sets environment variables using ridk if that's shipped with that Ruby.
      At present, the only other setting than 'default' is 'none', which only adds Ruby to PATH.
      No build tools are installed, nor are any ENV setting changed to activate them.
    default: 'default'

[eregon]

It also sets environment variables using ridk if that's shipped with that Ruby.

Do you know when ridk is present, is it always there for RubyInstaller builds?
And so it's not there for mingw/ucrt/mswin?

[MSP-Greg]

How about the following, I changed two things -

1. 'mingw/ucrt/mswin build tools' to 'mingw/ucrt/mswin build tools and packages'
2. 'ridk if that's shipped with that Ruby.' to ''ridk' or 'vcvars64.bat' based on the selected Ruby.'

  windows-toolchain:
    description: |
      This input allows to override the default toolchain setup on Windows.
      The default setting ('default') installs a toolchain based on the selected Ruby.
      Specifically, it installs MSYS2 if not already there and installs mingw/ucrt/mswin build tools and packages.
      It also sets environment variables using 'ridk' or 'vcvars64.bat' based on the selected Ruby.
      At present, the only other setting than 'default' is 'none', which only adds Ruby to PATH.
      No build tools are installed, nor are any ENV setting changed to activate them.
    default: 'default'

Thoughts? Note that it also uses an openssl package compatible with the selected Ruby.

[MSP-Greg]

Pushed the changes as above...

[eregon]

Thank you!

[eregon]

Having the default here is nice documentation-wise, but OTOH it has the side effect to always show this input (e.g. https://github.com/ruby/setup-ruby/actions/runs/7586102328/job/20663507608?pr=563#step:3:5) even though this input is likely to be used by very few.
So I'll remove this line to be consistent with other "non-required inputs".

[eregon]

Released as https://github.com/ruby/setup-ruby/releases/tag/v1.169.0