allows for proper building of LuaJit on Windows x64

[hidwood]

This pull request makes slight changes to the currently existing setup.py to bypass the check for the name of the platform to start with 'win'. This allows LuaJIT to be built successfully on my machines, two running Windows 10 and another running Ubuntu 20.04. I have no way to test this on a Mac, however I do not believe it should impact it in any way. The only potential issue I could see with this fix is one mentioned in #235 where the CI may fail due to a hardcoded Unix path. However, as I am currently not aware of how the directory structure may change under a windows build host, I am unable to make this alteration myself. If anyone knows if there is a change in the directory structure, I would be happy to implement that here as well as to not clutter the repository with merges.

[scoder]

The Windows build fails because we don't call msvcbuild.bat correctly from a VS prompt. I don't know how to do that. Any idea?

[scoder]

This explains it:
https://learn.microsoft.com/en-us/visualstudio/ide/reference/command-prompt-powershell?view=vs-2022#start-from-file-browser
However, it seems to suggest figuring out the absolute path to a VS batch script. :-/

[scoder]

It seems that vcvarsall.bat is what we want here:
https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170

[hidwood]

My apologies, I had been running from vcvars64 when I did my tests as that is usually something that one does when building cython projects on windows in my experience. I am not sure how one would find the location of vcvars64 or vcvarsall to build against however as it seems like it could be version specific. Additionally, I am unsure about the Visual Studio installation location on the CI.
By default, vcvarsall is found in "C:\Program Files\Microsoft Visual Studio<vs_version>\VC\Build," where <vs_version> is something like 2022 or 2019, and <variant> can be community, team, or enterprise. Additionally, it does not appear that an environment variable is created or added to path that would give the possible location of Visual studio. Without knowing this, I am not entirely sure how one could find it without hardcoding the path and hoping for the best, which is obviously not an optimal solution.

[hidwood]

I have added a check that searches for where I believe the file should be in the currently selected appveyor image. from what little I could find by looking through the install script. I found the following for reference:
""${env:ProgramFiles(x86)}\Microsoft Visual Studio\2019\Community""
When converted to a standard windows path that translates to "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community"
Hopefully this fixes the build issue, although I am not sure if ${env:ProgramFiles(x86)} mapps to somewhere else.

[scoder]

I don't think it helps to do this. IIUC, the batch file sets up environment variables, so it needs to run in the same command shell that then executes the build.

Also, I don't think it's a good idea to use a hard coded path. There must be a way to figure it out programmatically. It might also be that the batch file is simply on the search PATH already and can be started as is.

Note that appveyor isn't really used any more since we use GHA also for the Windows builds. I should disable it.