On some self-hosted runners "vswhere" is not available in the PATH.
Add another check in the findWithVswhere() function. It checks the
default installation of vswhere as stated by Microsoft, just in case
it is there but just not in the PATH.
Furthermore, the check refers to non-existent method core.warn()
instead of core.warning(). Use the correct method for reporting.
Recently added Visual Studio location with "vswhere" seems to be very
slow when using "-find" with path patterns. As in, 5 minutes slow.
vswhere does not provide much insight into why this happens, but I guess
that's because filesystem operations (and search in particular) are not
very fast on Windows.
Improve the search performance by combining vswhere with probing. Use
vswhere to locate the installation root, and then probe around for the
batch script we need.
Also, don't use vswhere for Visual Studio 2015 as it does not seem to
work. Rely only on probing here.
And also, add some debug logs so that it's possible to track which path
has been used, if you're interested in it.
The Windows images provided by GitHub have a native program called
"vswhere", which can be used to find vcvarsall.bat.
* use vswhere to find vcvarsall
* don't require child_process twice
* use vswhere to find the 2015 bat file
* refactor findWithVswhere
* move finding vcbuildtools using vswhere upward
* print error of vswhere
"Visual C++" has its build tool batch files in a different place.
Let's look there as well if we have not found 2017 or 2019 stuff.
Thanks to ReactOS project for figuring this out.
Co-authored-by: Victor Perevertkin <victor.perevertkin@reactos.org>
I'll probably use self hosted runners in a project and the Community
version of Visual Studio will be installed on those. This enables the
script to check for Community and Professional editions in addition
to the Entreprise one offered by GitHub.
The modification generates a kinda search map ordered by version then
by edition. It generates the batch script that runs vcvarsall.bat
on the fly given that search map.
Again, this is a squashed commit with around three hours of attempts
to write something working. See comments in the file for more details.
I'm too lazy to document this stuff properly.
Now that I know how to write some simple action, let's make a stub
more complete. For example, I already know what inputs I would like
to handle for this action.