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

[vcpkg, jsonnet, openssl-uwp] Enable use of the system powershell-core if it is present. #13805

Merged
merged 9 commits into from
Oct 28, 2020

Conversation

BillyONeal
Copy link
Member

@BillyONeal BillyONeal commented Sep 29, 2020

In #13267 we attempted to resolve failures to download PowerShell making the pool be relatively unstable by updating the version we look for to 7.0.3, and we have that version installed in the VMs. Unfortunately, this has not resulted in the reliability improvement we expected because vcpkg ignores the system copy. For example:

https://dev.azure.com/vcpkg/public/_build/results?buildId=43418&view=logs&j=5dffab7c-3299-5a76-7b02-e037cd868fad&t=70564965-7ae4-5af3-8764-a93ab8ddf245

[...]
A suitable version of powershell-core was not found (required v7.0.3). Downloading portable powershell-core v7.0.3...
Downloading powershell-core...
  https://github.com/PowerShell/PowerShell/releases/download/v7.0.3/PowerShell-7.0.3-win-x86.zip -> D:\downloads\PowerShell-7.0.3-win-x86.zip
Extracting powershell-core...
[...]

This change enables detection of a system pwsh.

Also note that callers in the scripts tree were changed to explicitly look for "pwsh" rather than "powershell". Previously we copied the binary under the old name which worked as a fallback, but this fails when pwsh is in Program Files:

D:\vcpkg\toolsrc\src\vcpkg-test\commands.build.cpp(16): FAILED:
due to unexpected exception with message:
  copy: Access is denied.: "C:\Program Files\PowerShell\7\pwsh.exe", "C:\
  Program Files\PowerShell\7\powershell.exe"

Also fixed a few ports to explicitly name pwsh for more consistent behavior, and drive by attempted to fix #12237 since the problem repro'd in the validation build for x86-windows 682fa1f.

@JackBoosY JackBoosY added category:infrastructure Pertaining to the CI/Testing infrastrucutre category:vcpkg-bug The issue is with the vcpkg system (including helper scripts in `scripts/cmake/`) info:internal This PR or Issue was filed by the vcpkg team. labels Sep 29, 2020
Copy link
Contributor

@ras0219-msft ras0219-msft left a comment

Choose a reason for hiding this comment

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

There is a remaining case of calling powershell.exe via vcpkg_build_msbuild(USE_VCPKG_INTEGRATION) -- this will pass flags to msbuild which pull in our standard applocal deployment stuff [1].

I recall when we spoke about this you mentioned that you tested some MSBuild cases and they didn't trigger the powershell bug, but I'm not sure if this specific one was considered.

The fix for this case is probably to add an internal VcpkgPowershell property to our MSBuild scripts that can be redirected to pwsh inside vcpkg but defaults to powershell outside.

[1]

if(_csc_USE_VCPKG_INTEGRATION)
list(
APPEND _csc_OPTIONS
/p:ForceImportBeforeCppTargets=${SCRIPTS}/buildsystems/msbuild/vcpkg.targets
"/p:VcpkgTriplet=${TARGET_TRIPLET}"
"/p:VcpkgCurrentInstalledDir=${CURRENT_INSTALLED_DIR}"
)
endif()

endif()
macro(search_for_dependencies PATH_TO_SEARCH)
file(GLOB TOOLS ${TOOL_DIR}/*.exe ${TOOL_DIR}/*.dll)
foreach(TOOL ${TOOLS})
vcpkg_execute_required_process(
COMMAND ${PS_EXE} -noprofile -executionpolicy Bypass -nologo
-file ${SCRIPTS}/buildsystems/msbuild/applocal.ps1
COMMAND ${PWSH_EXE} -noprofile -executionpolicy Bypass -nologo
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
COMMAND ${PWSH_EXE} -noprofile -executionpolicy Bypass -nologo
COMMAND "${PWSH_EXE}" -noprofile -executionpolicy Bypass -nologo

if (NOT DEFINED _VCPKG_POWERSHELL_PATH)
find_program(_VCPKG_PWSH_PATH pwsh)
if (_VCPKG_PWSH_PATH-NOTFOUND)
message(WARNING "vcpkg: Could not find PowerShell Core; falling back to PowerShell")
Copy link
Contributor

Choose a reason for hiding this comment

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

Since most users will not have PowerShell Core installed, this adds a warning for most/all users. I think we should probably not warn here.

@BillyONeal
Copy link
Member Author

There is a remaining case of calling powershell.exe via vcpkg_build_msbuild(USE_VCPKG_INTEGRATION) -- this will pass flags to msbuild which pull in our standard applocal deployment stuff [1].

Yes, this is the test I meant I tried. Consider activemq-cpp which uses that feature but I'm still left with a truetype font afterwards:

image

so I think we're good with no changes here.

@BillyONeal
Copy link
Member Author

The fix for this case is probably to add an internal VcpkgPowershell property to our MSBuild scripts that can be redirected to pwsh inside vcpkg but defaults to powershell outside.

That said I think this is an improvement even if it's unnecessary so I did that anyway.

@BillyONeal
Copy link
Member Author

Oh I see, we don't trigger the problem because in those places we set /p:VcpkgApplocalDeps=false so we never try to invoke the powershell. So I'm going to leave that alone.

@BillyONeal BillyONeal added the category:port-bug The issue is with a library, which is something the port should already support label Oct 8, 2020
@BillyONeal BillyONeal changed the title [vcpkg] Enable use of the system powershell-core if it is present. [vcpkg, vs-yasm, jsonnet, openssl-uwp] Enable use of the system powershell-core if it is present. Oct 8, 2020
set(_files yasm.props yasm.targets yasm.xml)
foreach(_file ${_files})
file(INSTALL "${SOURCE_PATH}/${_file}" DESTINATION "${CURRENT_PACKAGES_DIR}/share/${PORT}/")
endforeach()
set(_file "${CURRENT_PACKAGES_DIR}/share/${PORT}/yasm.props")
file(READ "${_file}" _contents)
string(REPLACE "$(VCInstallDir)" "" _contents "${_contents}")
string(REPLACE "$(VCInstallDir)" "${YASM_NATIVE}" _contents "${_contents}")
Copy link
Contributor

Choose a reason for hiding this comment

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

This inserts absolute paths into the package which will become invalid if it is restored elsewhere.

@JackBoosY
Copy link
Contributor

At the beginning, the use of powershell in the user system was prohibited because some functions in our script lacked compatibility in different versions. So this PR should focus on this issue.

@BillyONeal
Copy link
Member Author

At the beginning, the use of powershell in the user system was prohibited because some functions in our script lacked compatibility in different versions. So this PR should focus on this issue.

That's why this checks for the version and only uses the system one if the version matches

@BillyONeal BillyONeal changed the title [vcpkg, vs-yasm, jsonnet, openssl-uwp] Enable use of the system powershell-core if it is present. [vcpkg, jsonnet, openssl-uwp] Enable use of the system powershell-core if it is present. Oct 28, 2020
@BillyONeal
Copy link
Member Author

The failures are all the same as the most recent CI build, so merging this anyway.

@BillyONeal BillyONeal merged commit a6a1722 into microsoft:master Oct 28, 2020
@BillyONeal BillyONeal deleted the powershell_version branch October 28, 2020 03:48
strega-nil pushed a commit to strega-nil/vcpkg that referenced this pull request May 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:infrastructure Pertaining to the CI/Testing infrastrucutre category:port-bug The issue is with a library, which is something the port should already support category:vcpkg-bug The issue is with the vcpkg system (including helper scripts in `scripts/cmake/`) info:internal This PR or Issue was filed by the vcpkg team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[gmp:x64-windows] build failure
5 participants