Use mlocati/inspect-visualstudio GH Action to wrap vcvarsall.bat

[mlocati]

Configuring the environment variables used by Visual C++ is rather a nightmare.
That's why Microsoft provided helper batch files.

The one to be used to builc C/C++ projects is vcvarsall.bat.

Sadly, we can't use vcvarsall.bat direcly when using Visual C++ from Cygwin... For example the PATH environment variable must be in Cygwin notation (/cygdrive/c/...) (I guess you too tried it - see this useless step and this messy code).

That's why, for my gettext project for Windows I wrote the mlocati/inspect-visualstudio GitHub Action: it parses the variables set by vcvarsall.bat, so that other steps can use them.

What about switching to it?

PS: I launched a test run and it seems ok

[bhaible]

Hi Michele,

we can't use vcvarsall.bat direcly when using Visual C++ from Cygwin

Yes, this is the problem that I faced when trying to create a build environment for MSVC binaries using Cygwin.

Your https://github.com/mlocati/inspect-visualstudio project can certainly be helpful for users who don't want to set up the necessary environment variables manually. Although it looks like it has two problems:

• The dependency on TypeScript. In Cygwin you can assume bash to be available.
• The use of literal /cygdrive is wrong. It will not work for users who have customized their Cygwin mount table. In other words, /cygdrive/c is only the default mapping of C:. For correct file name conversion, the cygpath utility must be be used, because it is the only Cygwin tool or API that considers the actual mount table. See https://cygwin.com/cygwin-ug-net/using.html#using-pathnames and https://cygwin.com/cygwin-ug-net/cygpath.html .

In my ci-check projects, I would not like to make use of the inspect-visualstudio project because:

• While my approach with 5 base variables WindowsCrtIncludeDir, WindowsCrtLibDir, WindowsSdkIncludeDir, WindowsSdkLibDir, VSINSTALLDIR is tedious, it is conceptually simple: You have three components, and you describe where to find these components. Whereas your project adds complexity. If there are unexpected changes in future MSVC editions, the simple approach will likely be easier to adapt.
• I have documented these sets of assignments in the INSTALL.windows file of several projects. The purpose of the ci-check projects is also to make sure the documentation is correct. If the CI uses a different approach than the INSTALL.windows file, we don't have this verification any more.

[mlocati]

The dependency on TypeScript

Typescript is the source language. But it's transpiled to javascript (see here and here).
And nodejs (which is always available in github hosted runners) runs it's javascript "compiled" version.

The use of literal /cygdrive is wrong

Of course people installing cygwin in creative ways on github actions will have to process paths on their own. But it 's not the case here, isn't it?

Whereas your project adds complexity

It reduces completely IMHO: it uses vswhere to autodetect the available visual studio, and uses the vcvarsall utility that comes with visual studio to detect the build environment. Easy, secure and future proof.

I have documented these sets of assignments in the INSTALL.windows file of several projects

Of course a github action is only meant to be executed in a github environment, so it's orthogonal vs any other environment.

So, if one of the aims of this repo is to be sure the instructions in install.windows doc are ok, feel absolutely free to throw this PR in a trashcan 😉

[bhaible]

Of course a github action is only meant to be executed in a github environment, so it's orthogonal vs any other environment.

OK, I had imagined that you wanted this tool to be useful also for users who check out the GNU gettext sources from git or from a tarball and want to build them locally.

Whereas your project adds complexity

It reduces completely IMHO: it uses vswhere to autodetect the available visual studio, and uses the vcvarsall utility that comes with visual studio to detect the build environment. Easy, secure and future proof.

I agree that it makes things easy. But at the cost of added complexity (→ reduced transparency) and added dependencies.

This is a difficult trade-off. I've come to dislike these easy but complex wrappers over the years (from the Windows installers in .exe format, where a .zip would have been sufficient; up to the KDE NetworkManager app with its unpredictable behaviour).

I have documented these sets of assignments in the INSTALL.windows file of several projects

So, if one of the aims of this repo is to be sure the instructions in install.windows doc are ok, feel absolutely free to throw this PR in a trashcan 😉

Yeah, I know the next migration to a newer Visual Studio version or Windows version might cause a bit of work, to update the directory names. But that is not so much different to upgrading to a new Homebrew version on macOS.