Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allows for proper building of LuaJit on Windows x64 #251

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

hidwood
Copy link

@hidwood hidwood commented Dec 1, 2023

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
Copy link
Owner

scoder commented Dec 10, 2023

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
Copy link
Owner

scoder commented Dec 10, 2023

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
Copy link
Owner

scoder commented Dec 10, 2023

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
Copy link
Author

hidwood commented Dec 10, 2023

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
Copy link
Author

hidwood commented Dec 11, 2023

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.

Comment on lines +231 to +232
try:
subprocess.run(["C:\\Program Files(x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat", "x86_x64",])
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants