{{ message }}
Repository navigation
Allow building Mozc with Visual Studio 2026 - #1495
Merged
Merged
Conversation
yukawa
force-pushed
the
issue_1487
branch
3 times, most recently
from
April 29, 2026 03:10
13ba480 to
26c86a5
Compare
Collaborator
This makes Mozc build on machines where only Visual Studio 2026 is installed, while keeping Visual Studio 2022 as the default toolchain on machines where VS 2022 is available. GitHub Actions runners stay on VS 2022 for the time being; explicit opt-in to VS 2026 when both versions are present can be added in a subsequent commit. Three coordinated changes make this work: 1. Have vs_util.py call vswhere twice when the first call returns nothing: '[17,18)' first to find VS 2022, then '[18,19)' to find VS 2026. Combined with -latest, the resulting matrix is: * Only VS 2022 installed -> picks VS 2022 (no behavior change). * Only VS 2026 installed -> picks VS 2026. * Both installed -> picks VS 2022 (no behavior change). 2. Pass BAZEL_VC into the installer genrule's command line as --vs_install_dir, derive vcvarsall.bat from it inside build_installer.py, and feed it to vs_util as the path hint. Add --action_env=BAZEL_VC under config:windows_env so Bazel propagates the value into action environments. Without this, build_installer.py would run its own vswhere lookup and could pick a different VS than Bazel did, especially on machines with multiple installs. 3. Pick the CRT redist subfolder dynamically. The subfolder is named after the platform toolset, not the MSVC compiler version: VS 2022 stayed on toolset v143 even after MSVC ticked into the 14.4x range (to avoid breaking existing project files / CI pipelines), so its redist lives under 'Microsoft.VC143.CRT'. VS 2026 jumped the toolset to v145 (matching MSVC 14.50), skipping v144 entirely; its redist lives under 'Microsoft.VC145.CRT'. Read VCTOOLSVERSION (which vcvarsall.bat exports next to VCTOOLSREDISTDIR) and pick the v145 subfolder when the minor component is >=50, otherwise v143. Closes google#1487.
Collaborator
Author
hiroyuki-komatsu
added a commit
that referenced
this pull request
Jun 24, 2026
3.33.6133 → 3.33.6239 Conversion: * Updated the OSS dictionary [975d7d6] * Updated Zip code data as of 2026-04-03 [3e72fb3] * Added the circled zero (⓪) to number conversion candidates (#1520) [b18e5de] * Updated words for font names (#1449) [335c3c9] * Removed trailing space after small final sigma symbol (#1450) [5154bd8] * Android: Improved the word prediction feature [40dc336, c692321, cb87ab5] * Android: Improted the user history prediction feature [7684d80, 3350a19, a8f29ae, c5dd76f] Features: * Added support for mathematical functions (sin, cos, etc.) in the calculator rewriter [27710f2] * Added text sanitizer against ill-formed UTF-8 and ASCII control characters [fa11e0a, 61bdcfc] * Windows: Supported DPI change in candidate/infolist window (#1481) [fafbde9] Bug fix: * Android: Fixed ClearHistory failing to delete candidates with leading spaces [a8f245e] * Emacs: Fixed candidate overlay collapse when tab-line is enabled (#1507) [0c8acf4] * Emacs: Fixed backward compatibility for candidate window display in mozc.el (#1427) [891e324] * macOS: Fixed a failure of application launch [34c3187] * macOS: Correctly set RGB values for footer border color [0b71173] Code: * Removed Singleton class usages (#1461, #1463, #1464, #1465, #1475, #1477, #1478, #1479, #1480, #1490, #1491, #1497, #1498, #1499, #1502, #1509, #1510, #1513, #1514, #1515, #1523) * Avoided unnecessary string-resizes by using absl::StringResizeAndOverwrite (#1524, #1525) [ff20a11, 6fce2f3] * Replaced const std::string& with absl::string_view across multiple modules [988fbca, a801e2f, edc7cd0, 99aa820, 8c82922, 7e648b2] * Refactored candidate view design and renderer styling using RendererStyle and renderer_style.textproto [751df90, be6dd36, 67cede2, afbf1d0] * Refactored FlatConcurrentCache memory footprint and insert API [c891133, 3a4130b] * Refactored UserPos cost mapping to generate kPosTypeStringTable dynamically from user_pos.def [53de4e4, 8c190e5, a20e4c1, 70fdb7f] * Decoupled ImmutableConverter and DictionaryInterface from ConversionRequest and extracted Options [2ee4da3, 6ba80c7, b30921c] * Refactored ConfigDialog UI layouts and frame mechanisms [4638ce6, c79a760, 895652c, 3c327d8] * Removed Lemon-based parser for CalculatorRewriter [cb95326, e96c1ba] * Removed Breakpad integration [1078e63] * Removed unused ServerLauncher::set_server_program (#1466) [a524a88] * Removed --timeout/--restricted from renderer (#1494) [be0eb82] * Removed an optional optimization for uniprocessor (#1501) [5381793] * Removed zstring_view [61068fe] * Fixed name shadowing in QtIpcServer constructor (#1486) [8cb8458] * Used unique service names in renderer_server_test (#1433) [858f8c0] * Made RendererStyleHandler platform-neutral (#1474) [e4cb300] * Applied standard code formatter to mac/ and unix/ directories [3024194] * Linux: Made the default Qt path relative to the workspace root [5d46097] * Linux: Removed generation of IBus engine XML and moved IBus config textproto to a dedicated file [2c84656, fb22406, dacc0a4] * macOS: Consolidated ios and macos selections into apple in mozc_select [96c86c0] * macOS: Made MacStatsConfigUtilImpl stateless (#1496) [5fc301c] * Windows: Simplified GetDPIScalingFactor for Windows (#1467) [04a1ed3] * Windows: Always used "en-US" in HResult::ToString() (#1476) [7c1f61c] * Windows: Fixed MSVC extension warnings in WinAPITestHelper (#1492) [8cb5cc3] * Windows: Defined NO_SHLWAPI_STRFCNS to not define StrCat (#1508) [fdfcc30] * Windows: Always evaluate ServerLauncher::server_program() (#1473) [45c33ae] Build: * Updated Bazel version to 9.0.2 [3ced4c8] * Removed git submodules [32be060, 48bbbf7, efaae55] * Moved src/data/version/mozc_version_template.bzl to src/version.bzl [68d04b2] * Made //engine:data_loader_test deterministic (#1522) [9afbd98] * Worked around QTBUG-145239 with a local patch (#1506) [9df9774] * Removed redundant build options from instructions (#1489) [180ef9f] * Android: Separated android_util into its own dedicated build target [060b96e] * Bazel: Made build rules compatible with Bazel 8.6 / 9.0 and updated external dependencies (#1451, #1453, #1454) [6c19ff0, 7cad196, 684c1d4, 979a650] * Windows: Allowed building Mozc with Visual Studio 2026 (#1495) [b940437] * Windows: Updated minimum Windows version to 1809 (build 17763) [3792d79] * Windows: Always used CustomAction to register COM DLLs (#1500) [82dca34] * Windows: Introduced mozc_win32_resource alias and universal MSI installer build support (#1434) [ecf3825, bab1403, 96bab12] * Windows: Used ARM64-native Ninja and LLVM binaries (#1382, #1460) [67e9d9e, 430ac03] * Registered Mozc Starlark macros with build_cleaner [e3e467e] PiperOrigin-RevId: 937168930
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Description
This makes Mozc build on machines where only Visual Studio 2026 is installed, while keeping Visual Studio 2022 as the default toolchain on machines where VS 2022 is available. GitHub Actions runners stay on VS 2022 for the time being; explicit opt-in to VS 2026 when both versions are present can be added in a subsequent commit.
Three coordinated changes make this work:
Have
vs_util.pycallvswheretwice when the first call returns nothing:[17,18)first to find VS 2022, then[18,19)to find VS 2026. Combined with-latest, the resulting matrix is:Pass
BAZEL_VCinto the installergenrule's command line as--vs_install_dir, derivevcvarsall.batfrom it insidebuild_installer.py, and feed it tovs_utilas the path hint. Add--action_env=BAZEL_VCunderconfig:windows_envso Bazel propagates the value into action environments. Without this,build_installer.pywould run its ownvswherelookup and could pick a different VS than Bazel did, especially on machines with multiple installs.Pick the CRT redist subfolder dynamically. The subfolder is named after the platform toolset, not the MSVC compiler version: VS 2022 stayed on toolset v143 even after MSVC ticked into the 14.4x range (to avoid breaking existing project files / CI pipelines), so its redist lives under
Microsoft.VC143.CRT. VS 2026 jumped the toolset to v145 (matching MSVC 14.50), skipping v144 entirely; its redist lives underMicrosoft.VC145.CRT. ReadVCTOOLSVERSION(whichvcvarsall.batexports next toVCTOOLSREDISTDIR) and pick the v145 subfolder when the minor component is >=50, otherwise v143.Closes #1487.
Issue IDs
Steps to test new behaviors (if any)
python build_tools/build_qt.py --release --confirm_licensebazelisk build --config release_build package