[Build] Fix UTF-8 and output paths for local C++ builds - #49575
[Build] Fix UTF-8 and output paths for local C++ builds#49575gavinzhangth wants to merge 2 commits into
Conversation
Compile ZoomIt and Keyboard Manager engine projects as UTF-8 so builds do not depend on the active Windows code page. Use RepoRoot-based paths and standard output directories for direct Keyboard Manager project builds.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
The CP 936 issue is a good catch. cl.exe will use the current code page if it's not given Is it better to add I don't know enough about the intricacies of the build to comment on the |
|
Thanks, agreed. I moved |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
| <Error Condition="!Exists('$(RepoRoot)packages\Microsoft.Windows.CppWinRT.2.0.250303.1\build\native\Microsoft.Windows.CppWinRT.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(RepoRoot)packages\Microsoft.Windows.CppWinRT.2.0.250303.1\build\native\Microsoft.Windows.CppWinRT.targets'))" /> | ||
| </Target> | ||
| </Project> No newline at end of file | ||
| </Project> |
There was a problem hiding this comment.
Please remove the addtional line
|
Looks good overall |
Summary of the Pull Request
Fixes two local C++ build reliability problems:
Cpp.Build.props, so builds do not depend on the active Windows code page. On code page 936, UTF-8 punctuation in BOM-less source files otherwise triggers C4819 and fails the build because warnings are treated as errors.$(RepoRoot)for Keyboard Manager repository paths and standardizes native/test output directories. This makes direct project builds find the resource conversion script and headers, places the Editor wrapper beside the WinUI app, and keeps the Engine test DLL under the repository test output directory.No runtime logic, end-user strings, dependencies, or binaries are added.
PR Checklist
Detailed Description of the Pull Request / Additional comments
Directory.Build.propsimportsCpp.Build.propsfor C++ projects. Defining/utf-8 %(AdditionalOptions)in its sharedClCompilesettings makes source decoding deterministic across the native codebase and prevents future BOM-less UTF-8 source files from reintroducing the same locale-dependent failure./utf-8explicitly sets both the source and execution character sets instead of suppressing C4819 or replacing valid Unicode text.$(SolutionDir)is only reliable when MSBuild is invoked through a solution. The repository's local build script builds.vcxprojfiles directly from their project directories, where$(RepoRoot)is the stable repository root property. The wrapper output now follows the existing$(RepoRoot)$(Platform)\$(Configuration)\WinUI3Apps\pattern used by other native WinUI dependencies.Validation Steps Performed
All successful builds used the repository build scripts with
-Platform x64 -Configuration Debug.tools/build/build-essentials.cmd: solution restore, Runner, and Settings all succeeded with empty errors logs.FancyZonesLibsuccessfully after it had failed with a resource-related CL exit during a full parallel build.WorkspacesModuleInterfacesuccessfully, validating that existing UTF-16 BOM headers remain compatible with the shared option.ZoomItBreakandZoomItsuccessfully.KeyboardManagerEngineTestsuccessfully.KeyboardManagerEditorandKeyboardManagerEditorUIsuccessfully after the documented essentials prerequisite./utf-8compiler invocations and all correspondingbuild.debug.x64.errors.logfiles are empty.vstest.console.exeagainst the Keyboard Manager Engine test assembly: 103/103 passed.PowerToys.KeyboardManagerEditorLibraryWrapper.dllis emitted tox64/Debug/WinUI3Apps.KeyboardManager.Engine.UnitTests.dllis emitted tox64/Debug/tests/KeyboardManagerEngine.A full
PowerToys.slnxx64 Debug build was attempted twice. The first attempt exhausted the remaining 62 MB of disk space. After clearing 52.46 GB of ignored build outputs, the second attempt still exceeded the machine's temporary disk/commit limits (CL.exeexit0xC000012Dand an out-of-space cppwinrt write). Before that resource failure, the log contained 4,642/utf-8command entries and no character-set diagnostics. The full configuration matrix is left to PR CI rather than bypassing normal build settings locally.