Skip to content

Conversation

@wesm
Copy link
Member

@wesm wesm commented Feb 4, 2020

This resolves the issues I was having as described in ARROW-6757. This does not fix the Python 3.8 wheel, though

@rem This is the path for Visual Studio Community 2017
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat" -arch=amd64

cmake -G "Ninja" ^
Copy link
Member Author

Choose a reason for hiding this comment

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

If anyone knows how to control the MSVC version used by Ninja let me know

Copy link
Member

Choose a reason for hiding this comment

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

This is usually done by calling the vcvarsall.bat script for the particular MSVC install (or apparently VsDevCmd in more recent versions).

Copy link
Member Author

Choose a reason for hiding this comment

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

We had this conversation in the past, I think. The MSVC "environment setup" scripts provided by VS are more crude than what can be obtained using the -G flag.

Using an explicit generator it's possible to choose the exact toolchain you want, but you must use msbuild, not Ninja. It would be interesting to know if there's a way to both use Ninja and select the target toolchain. The answer may be no but anyway it would be nice to know

Copy link
Member

Choose a reason for hiding this comment

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

I didn't try it but we may be able to use -DMSVC_TOOLSET_VERSION=142 for Visual C++ 2019 or something: https://cmake.org/cmake/help/latest/variable/MSVC_TOOLSET_VERSION.html#variable:MSVC_TOOLSET_VERSION

@github-actions
Copy link

github-actions bot commented Feb 4, 2020

@pitrou
Copy link
Member

pitrou commented Feb 4, 2020

Could you open a JIRA to remove the hardcoded CMake generator in setup.py?

@wesm
Copy link
Member Author

wesm commented Feb 4, 2020

+1. I'll open a JIRA (though I'm not sure how we will get setup.py to choose the right generator if one is not passed)

@wesm
Copy link
Member Author

wesm commented Feb 4, 2020

@wesm wesm closed this in b7dbbcc Feb 4, 2020
@wesm wesm deleted the windows-rc-verify-fixes branch February 4, 2020 18:35
kszucs pushed a commit that referenced this pull request Feb 7, 2020
…n verifying RC, remove Python 3.5 from wheel verification

This resolves the issues I was having as described in ARROW-6757. This does not fix the Python 3.8 wheel, though

Closes #6350 from wesm/windows-rc-verify-fixes and squashes the following commits:

a9d4c66 <Wes McKinney> Fixes for Windows release verification scripts

Authored-by: Wes McKinney <[email protected]>
Signed-off-by: Wes McKinney <[email protected]>
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.

3 participants