-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
[opengl] Use WindowsSdkDir and WindowsSdkVersion from vcvars to get the Windows SDK path correctly #11261
Conversation
…dows SDK path correctly
@@ -0,0 +1,6 @@ | |||
# Returns Windows SDK path via out variable "ret" | |||
function(vcpkg_get_windows_sdk_path ret) | |||
set(WINDOWS_SDK_PATH $ENV{WindowsSdkDir}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need a pass-through to be visible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cenit think we need to abstract these "concrete" functions, and there is no need to consider the specific acquisition process of these variables in portfile.cmake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vcpkg provides basic interfaces and variables, and portfile.cmake
provides business processes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes sure I just mean: is $ENV{WindowsSdkDir}
visible when running cmake inside vcpkg, that masks almost all environment variables?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, I'm not sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cenit It looks like that one is added by vcvarsall so we expose it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vcvars is not loaded when chainload toolchain file is set, does it mean that any port using vcpkg_get_windows_sdk_path
can't be build in that scenario?
Related to #8329 |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
vcpkg_get_program_files_32_bit(PROGRAM_FILES_32_BIT) | ||
vcpkg_get_windows_sdk(WINDOWS_SDK) | ||
vcpkg_get_windows_sdk_path(WINDOWS_SDK_PATH) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The port should be able to use the WindowsSdkDir environment variable directly, there is no need to have this function adding a level of indirection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vicroms @ras0219 @ras0219-msft
I think that for system or compiler variables, we should provide unified functions to contributors, because contributors do not need to pay attention to these things. And the Windows SDK PATH has been directly used in some ports, we have reason to provide a unified function to deal with it.
Fixes #8288 |
0c2cde1
to
ce38903
Compare
…ding Windows SDK paths. Also delete vcpkg_get_program_files_32_bit because it was used in only one place. Resolves microsoft#8288 Obsoletes microsoft#11421, microsoft#11261, microsoft#8329
…ding Windows SDK paths. (microsoft#12232) Also delete vcpkg_get_program_files_32_bit because it was used in only one place. Resolves microsoft#8288 Obsoletes microsoft#11421, microsoft#11261, microsoft#8329
Use environment variables instead of specified values to get the Windows SDK path.
Fix #11179 #8288