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.

Sign up for GitHub

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

Jump to bottom

Use bazel to build Mozc for Windows #948

Closed
yukawa opened this issue Jun 19, 2024 · 1 comment
Closed

Use bazel to build Mozc for Windows #948

yukawa opened this issue Jun 19, 2024 · 1 comment

Comments

@yukawa
Copy link
Collaborator

yukawa commented Jun 19, 2024 •
edited
Loading

Description

This is a placeholder issue to keep track of remaining tasks to migrate to Bazel in Windows build.

Version or commit-id

07ce456
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Add Qt for Windows support to Bazel build.
019911b 
As a preparation to support Bazel for Windows build (#948), this makes
"qt_win" repository available for Bazel build on Windows.

There must be no observable behavior change in mac/Linux Bazel builds.

PiperOrigin-RevId: 645598529
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Define C/C++ macros for oss_windows
316d877 
This is a preparation to support Bazel for Windows build (#948).

There must be no observable behavior change in mac/Linux Bazel builds.

#codehealth

PiperOrigin-RevId: 645598550
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Remove unnecessary "-Wno-parentheses" from copts
c31ace6 
Seems that we do not see any warning even after removing this

  -Wno-parentheses

compiler option. Let's remove it as otherwise it breaks msvc build.

This is a preparation to support Bazel for Windows build (#948).

#codehealth

PiperOrigin-RevId: 645601836
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Add config_setting for compiler.
7b65824 
As a preparation to support Bazel for Windows build (#948), this commit
introduces a convenient way for each BUILD.bazel file to change the
behavior depending on whether the compiler is msvc-like or not.

#codehealth

PiperOrigin-RevId: 645611936
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Make build_defs.bzl compatible with msvc
5f5b4c3 
Otherwise msvc complains as it does not recognize "-funsigned-char".

This is a preparation to support Bazel for Windows build (#948).

#codehealth

PiperOrigin-RevId: 645614326
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Make .bazelrc compatible with msvc
7eeb752 
Currently our .bazelrc specifies C/C++ options with an assumption that
the compiler recognizes gcc-like options, which of course do not work
when msvc is used. In order to support Bazel Windows build (#948),
it needs to be updated to specify copts based on the target environment.

There must be no observable behavior change in mac/Linux Bazel builds.

#codehealth

PiperOrigin-RevId: 645619204
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Add an additional bazelrc file for Windows.
9adf5ce 
This is a workaround for the path-length issue on building protobuf on
Windows with bazel.

 * protocolbuffers/protobuf#12947
 * bazelbuild/bazel#18683

To work around it, specify --bazelrc=windows.bazelrc as follows.

  bazel --bazelrc=windows.bazelrc   \
        build //protocol:commands_proto  \
        --config oss_windows

This is a preparation to support Bazel for Windows build (#948).

There must be no observable behavior change in mac/Linux Bazel builds.

PiperOrigin-RevId: 645622326
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Add mozc_cc_win32_library rule to build DLL import library
78178f6 
With this commit we can actually start being able to build the following
build targets.

 * //win32/base:input_dll
 * //win32/base:input_dll_test
 * //win32/base:msctf_dll
 * //win32/base:msctf_dll_test

See the following commits about how the above targets are used.

 * f470414
 * 006084c

This is a preparation to support Bazel for Windows build (#948).

There must be no change in non-Windows build targets.

#codehealth

PiperOrigin-RevId: 645622807
hiroyuki-komatsu pushed a commit that referenced this issue Jun 24, 2024
@yukawa @hiroyuki-komatsu
Add missing dependencies to build mozc_tool.exe
d1e7efb 
This is a preparation to support Bazel for Windows build (#948).

There must be no change in non-Windows build targets.

#codehealth

PiperOrigin-RevId: 645632434
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Fix deps of mozc_tool_main_lib on Windows
08c0674 
This is a follow up commit to my previous commit [1], which aimed to
enable us to build mozc_tool on Windows with msvc (#948).

The correct label of winmain target is base/win32:winmain.

 [1]: d1e7efb

#codehealth

PiperOrigin-RevId: 646276468
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Make .bazelrc compatible with msvc (part 2)
7405cc4 
This is a follow up commit to my previous commit [1], which aimed to
make .bazelrc compatible with msvc (#948).

 * also add a rule to automatically set --config=compiler_msvc_like
   for windows targets.
 * also add /Zc:__cplusplus option as we did with GYP build [2]

 [1]: 7eeb752
 [2]: 3ea897d

#codehealth

PiperOrigin-RevId: 646276811
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Remove unnecessary -Wno-parentheses from copts (part 2)
703a7f8 
This is a follow up commit to my previous commit [1], which aimed to
remove unnecessary "-Wno-parentheses" option from copts, as otherwise
msvc build fails with unsupported options (#948).

Apparently mozc_data.bzl still contains the option in question.
Let's remove it as well.

 [1]: c31ace6

#codehealth

PiperOrigin-RevId: 646277073
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Add a rule to build Windows executables w/ custom build configs
5efa371 
This CL adds a custom rule `mozc_win_build_rule` to build Windows
executables with the given build configurations. This rule is necessary
to build Windows executables with the correct build configurations,
such as the CPU architecture and the CRT library.

For instance, the following build rule tells Bazel to have
"custom_action" target with "x64_windows" CPU architecture and with
statically linking to MSVC C++ runtime.

  mozc_win_build_rule(
      name = "custom_action",
      target = "//win32/custom_action:custom_action",
      cpu = "x64_windows",
      static_crt = True,
  )

This CL is a part of the effort to migrate the Windows build system
from GYP to Bazel (#948).

#codehealth

PiperOrigin-RevId: 646324022
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Add a build rule //win32/installer:executables
cd37f5a 
As a preparation to build Mozc installer for Windows (#948), this commit
adds a rule to build all the Mozc executables to be installed with the
correct build configurations (e.g. CPU architecture, CRT link type).

  bazel --bazelrc=windows.bazelrc               \
        build //win32/installer:artifacts       \
        --config oss_windows --cpu=x64_windows

Keep in mind that there still remain many known issues in these
executables. They are not yet ready to correctly run in real devices.

 * Win32 resources are not yet embedded
 * manifest files are not yet embedded
 * some security related compiler / linker flags are not yet set
   (e.g. '/CETCOMPAT' and /DEPENDENTLOADFLAG)

PiperOrigin-RevId: 646329541
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Enable minimum CI for Windows bazel build
421ecca 
As a preparation to support Bazel for Windows build (#948), we start
enabling an experimental CI rule for Windows bazel build.

#codehealth

PiperOrigin-RevId: 646330047
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Temporarily simplify magic header check in *_data_manager.cc
3f1570b 
Historically we have passed the entire magic number of the embedded data
file to each *_data_manager.cc file so that it can compare the values
at run time. However the problem here is that propagating non-ASCII byte
data from the build system to *.cc file is not that simple task. This is
going to be more problematic when we start using Bazel on Windows, where
the backslash character has another special path separator meaning.

As a temporary solution to unblock Bazel migration (#948), this commit
relaxes the verification by only propagating the magic number byte
length instead of the entire byte array. Note that each data file still
has a checksum and the data integrity remains to be verifiable . The only
thing we can no longer verify is some accidental mistakes at the build
rules level, which is supposed to be unlikely to happen.

PiperOrigin-RevId: 646540433
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Temporarily revert //win32/installer:artifacts
ff64988 
This is a follow up commit to my previous commits, which added

  //win32/installer:artifacts

target to build Mozc with Bazel on Windows (#948).

It seems that it has caused some build errors in other platforms.
Let's revert them back until we figure out how to solve the issue.

#codehealth

PiperOrigin-RevId: 646670786
hiroyuki-komatsu pushed a commit that referenced this issue Jun 26, 2024
@yukawa @hiroyuki-komatsu
Fix macOS builds due to typos in .bazelrc
cccb244 
This is a follow up commit to my previous commit [1], which aimed to add

  --noincompatible_enable_cc_toolchain_resolution

build option only to Windows builds as a preparation to support Bazel
build on Windows (#948). It, however, accidentally set the flag to mac
builds, which is why now macOS builds are failing.

With this commit the flag is set only to Windows builds as intended.

#codehealth

 [1]: 5efa371

PiperOrigin-RevId: 646703582
hiroyuki-komatsu pushed a commit that referenced this issue Jun 28, 2024
@yukawa @hiroyuki-komatsu
Fix deps of post_install_dialog on Windows
0fe3905 
This is a follow up commit to my previous commits [1][2], which aimed to
enable us to build mozc_tool on Windows with msvc (#948).

Having the same dependency multiple times results in an error. Thus it
needs to be removed.

 [1]: d1e7efb
 [2]: 08c0674

#codehealth

PiperOrigin-RevId: 646727649
hiroyuki-komatsu pushed a commit that referenced this issue Jun 28, 2024
@yukawa @hiroyuki-komatsu
Also build mozc_tool with Bazel on GitHub Actions
4e4645c 
We can now build mozc_tool.exe with Bazel on Windows (#948). Let's start
continuously building it as well as mozc_server.exe on GitHub Actions.

#codehealth

PiperOrigin-RevId: 646729912
hiroyuki-komatsu added a commit that referenced this issue Jul 8, 2024
@hiroyuki-komatsu
Update BUILD_OSS to 5520
183b5e8 
Features
* Improved the AD to Era conversion: "2024ねん" → "令和6年" (6ceada3)
* Increased word vocabulary (4f03239)
* Updated the reading correction rules (3a665b1)

Bug fix
* Fixed the issue that Bazel build Included entries in dictionary_manual/ by Bazel (47eb877)
* macOS: Fixed jaggy icons for the GUI tools (#964)

Build
* Updated the Qt version: 6.7.1 → 6.7.2 (#963)
* Supported dictionary_manual/words.tsv as additional dictionary entries (8d3a297)
* Windows: Added CI of Bazel for the converter and GUI tools (#948)

Code
* Performed refactorings for the converter and Bazel rules.

PiperOrigin-RevId: 650203535
@hiroyuki-komatsu hiroyuki-komatsu mentioned this issue Jul 21, 2024
Closed
@yukawa yukawa mentioned this issue Sep 6, 2024
Closed
hiroyuki-komatsu pushed a commit that referenced this issue Sep 28, 2024
@yukawa @hiroyuki-komatsu
Add data/images/win/BUILD.bazel
52d34bc 
As a preparation to use Bazel to build Mozc for Windows (#948), this
commit makes image files under data/images/win/ visible to other build
rules.

There must be no observable behavior change in GYP build for Windows.

PiperOrigin-RevId: 679429017
hiroyuki-komatsu pushed a commit that referenced this issue Sep 28, 2024
@yukawa @hiroyuki-komatsu
Make gen_win32_resource_header compatible with bazel
57990a2 
As a preparation to use Bazel to build Mozc for Windows (#948), this
commit makes gen_win32_resource_header.py compatible with Bazel.

There must be no observable behavior change in GYP build for Windows.

PiperOrigin-RevId: 679455715
hiroyuki-komatsu pushed a commit that referenced this issue Sep 28, 2024
@yukawa @hiroyuki-komatsu
Add --utf8 option to gen_win32_resource_header.py
3315557 
As a preparation to use Bazel to build Mozc for Windows (#948), this
commit adds --utf8 to gen_win32_resource_header.py to generate a
resource file with UTF-8 when specified.

There must be no observable behavior change in GYP build for Windows.

PiperOrigin-RevId: 679600674
hiroyuki-komatsu pushed a commit that referenced this issue Sep 28, 2024
@yukawa @hiroyuki-komatsu
Ensure build number does not exceed 16-bit on Windows
3e437ca 
As a preparation to use Bazel to build Mozc for Windows (#948), this
commit makes sure that the build number will never exceed 16-bit on
Windows, which is required by the Win32 version resource format.

There must be no observable behavior change unless version override
is specified.

PiperOrigin-RevId: 679859359
hiroyuki-komatsu pushed a commit that referenced this issue Sep 28, 2024
@yukawa @hiroyuki-komatsu
Take gen_win32_resource_header.py into account in Bazel build
8f1db1e 
As a preparation to use Bazel to build Mozc for Windows (#948), this
commit makes sure that gen_win32_resource_header.py is actually used
to generate the final *.rc file to be compiled.

Note that actual Win32 resource compile is still a stub, which will
be implemented in a subsequent commit.

There must be no observable behavior change in GYP build.

PiperOrigin-RevId: 679874821
hiroyuki-komatsu pushed a commit that referenced this issue Sep 28, 2024
@yukawa @hiroyuki-komatsu
Support Win32 resource in Bazel build
cc9e050 
With this commit, Win32 resource and manifest start being embedded into
the final executables even for Bazel build (#948).

There must be no observable behavior change in GYP build.

PiperOrigin-RevId: 679898803
hiroyuki-komatsu pushed a commit that referenced this issue Sep 29, 2024
@yukawa @hiroyuki-komatsu
Add missing Win32 resource deps for Bazel build
9a9ccf2 
This is a preparation to use Bazel to build Mozc for Windows (#948).

The following executables still do not have Win32 resources due to
missing build dependencies.

 * custom_action.dll
 * mozc_tool.exe
 * mozc_cache_service.exe

With this commit these executables start having Win32 resources.

There must be no observable behavior change in GYP build.

PiperOrigin-RevId: 680116607
hiroyuki-komatsu pushed a commit that referenced this issue Sep 29, 2024
@yukawa @hiroyuki-komatsu
Remove an unused load statement from src/win32/base/BUILD.bazel
8bc7db2 
This is a preparation to use Bazel to build Mozc for Windows (#948).

#codehealth

PiperOrigin-RevId: 680137142
hiroyuki-komatsu pushed a commit that referenced this issue Sep 29, 2024
@yukawa @hiroyuki-komatsu
Add dotnet_tool_repository rule to download wix
4e7b736 
This is a preparation to use Bazel to build Mozc for Windows (#948).

With this commit, we can start referencing to wix.exe from Bazel rules.

Note that dotnet-tools.json, which we introduced for #894 [1], does not
work well with Bazel because we cannot assume current working directory
when running Bazel action.  We instead download the WiX executable with

  --tool-path

option so that WiX can be executed from any current working directory.

Note also that there must be no observable behavior change in GYP build.

 [1]: cbd5556

PiperOrigin-RevId: 680138030
hiroyuki-komatsu pushed a commit that referenced this issue Sep 29, 2024
@yukawa @hiroyuki-komatsu
Build Win32 executables with required build config
ea55af0 
As a preparation to use Bazel to build Mozc for Windows (#948), this
commit reworks my previous attempts [1][2], which aimed to make it
configurable on which executable should be built with what build
configurations (e.g. CRT link type, target CPU architecture).

For instance, the following command will build mozc_tool with dynamic
CRT for 64-bit, and mozc_tip32 with static CRT for 32-bit.

  bazel --bazelrc=windows.bazelrc build  \
      //win32/installer:mozc_tool        \
      //win32/installer:mozc_tip32       \
      --config oss_windows

There must be no observable behavior change in GYP build.

 [1]: 5efa371
 [2]: ff64988

PiperOrigin-RevId: 680165643
hiroyuki-komatsu pushed a commit that referenced this issue Sep 29, 2024
@yukawa @hiroyuki-komatsu
Define _WIN64 when invoking rc.exe for 64-bit arch
1e831ba 
This follows up to my previous commit [1], which implemented an initial
support for Win32 resources in our bazel build rules (#948).

One thing I overlooked was that

  win32/tip/tip_resource.rc

has assumed that _WIN64 macro is defined when it is compiled as 64-bit
executable. As a result, its "OriginalFilename" field remains to be
mozc_tip32.dll even when its actual file name is mozc_tip64.dll.

Let's fix it by also defining _WIN64.

There must be no observable behavior change in GYP build.

 [1]: cc9e050

PiperOrigin-RevId: 680165743
hiroyuki-komatsu pushed a commit that referenced this issue Sep 30, 2024
@yukawa @hiroyuki-komatsu
Support building installer for Windows with Bazel
ffc460e 
As a milestone of our on-going effort to support Bazel to build Mozc
for Windows (#948), we can finally start building the installer of Mozc
for Windows with Bazel with this commit.

While there remain several things to be followed up (e.g. compiler
options and linker options for production builds), it should now just
work in an end-to-end manner.

PiperOrigin-RevId: 680400073
hiroyuki-komatsu pushed a commit that referenced this issue Sep 30, 2024
@yukawa @hiroyuki-komatsu
Set correct target_compatible_with in win32/installer/transition.bzl
e06fa8c 
This follow up to my previous commit [1] for #948.

An updated version of "target_compatible_with" should have been passed
there.

 [1]: ea55af0

PiperOrigin-RevId: 680403001
hiroyuki-komatsu pushed a commit that referenced this issue Sep 30, 2024
@yukawa @hiroyuki-komatsu
Fix missing product_icon.ico target and visibility
b92c4fd 
This follow up to my previous commit [1], which aimed to start
supporting Mozc installer for Windows with Bazel (#948).

There were a missing target and visibility. With this commit it should
finally start working.

 [1]: ffc460e

PiperOrigin-RevId: 680454012
hiroyuki-komatsu pushed a commit that referenced this issue Oct 1, 2024
@yukawa @hiroyuki-komatsu
Use the same fine names for installer when building with Bazel
995d96b 
This is another follow up commit to my previous commits [1], which aimed
to start supporting Mozc installer for Windows with Bazel (#948).

In GYP builds we used to have 64 suffix in the file names of Mozc
installers. Let's do the same thing for now to make our build system
transition simpler.

With this commit 'Mozc64_bazel.msi' finally starts showing up on the
GitHub Actions artifacts section.

 [1]: ffc460e
 [2]: b92c4fd

PiperOrigin-RevId: 680747948
hiroyuki-komatsu pushed a commit that referenced this issue Oct 1, 2024
@yukawa @hiroyuki-komatsu
Remove unused windows.resource_files from stub.bzl
8dfa228 
This has been unused since my commit [1] for #948.

 [1]: cc9e050

#codehealth

PiperOrigin-RevId: 680748809
hiroyuki-komatsu pushed a commit that referenced this issue Oct 3, 2024
@yukawa @hiroyuki-komatsu
Remove an obsolete workaround from .bazelrc
de7615f 
This follows up to my previous commit [1], which was added as a
temporary workaround while working on Bazel build for Windows (##948).

As of Bazel 7.3.2 with bzlmod enabled,

  --noincompatible_enable_cc_toolchain_resolution

looks to be no longer necessary. Let's remove it for simplicity.

 [1]: 5efa371

#codehealth

PiperOrigin-RevId: 681690120
hiroyuki-komatsu pushed a commit that referenced this issue Oct 4, 2024
@yukawa @hiroyuki-komatsu
Start using vswhere.exe in vs_util.py
ace3145 
Unlike GYP build, we cannot simply pass '--vcvarsall_path' in Bazel
build for Windows (#948). To support environment where Visual C++ is
installed in a non standard directory, 'vs_util.py' starts using
'vswhere.exe' [1] with this commit.

See also #1057.

 [1]: https://github.com/microsoft/vswhere

PiperOrigin-RevId: 682300183
@yukawa
Copy link
Collaborator Author

yukawa commented Oct 5, 2024

Closing as we can at least build Mozc64.msi, which is basically usable.

Remaining tasks (e.g. migrating compile / link options such as /LTCG, /DEPENDENTLOADFLAG, /CETCOMPAT, updating the documentation) will be handled in separate issues/tasks.

@yukawa yukawa closed this as completed Oct 5, 2024
hiroyuki-komatsu pushed a commit that referenced this issue Oct 7, 2024
@yukawa @hiroyuki-komatsu
Add Scheuklappen: keep for Win32 bazel targets
c60fbba 
These targets are used used only for Bazel build for Windows (#948).

Without this annotation our bot may restrict these visibility
automatically in the future.

PiperOrigin-RevId: 682324437
hiroyuki-komatsu added a commit that referenced this issue Oct 10, 2024
@hiroyuki-komatsu
Update BUILD_OSS to 5618
1d74ac4 
2.30.5595 → 2.30.5618

Conversion
* Updated zip code entries (#1063).
* Updated word entries (#1068, #1069)

Bug fix
* Linux: Enabled switching to the DIRECT mode from the menu (#1061)
* Linux: Enabled switching modes with Super+Space in Wayland (#853, #1059)
* macOS: Fixed the limitation of mouse clicking on the renderer on macOS 15 (120bd93)
* Windows: Fixed the setting of Omaha updater for the GoogleJapaneseInput build (#1072)

Build
* Android: Switched the Bazel rules from WORKSPACE to Bzlmod (#1002)
* Android: Updated the Docker build environment
* Linux: Update the build environment: Ubuntu 22.04 → 24.04 (#924)
* macOS / Windows: Updated the Qt version: 6.7.2 → 6.7.3 (#1065)
* Windows: Supported Bazel build (#948)
* Windows: Updated the Wix version: 4.0.5 → 5.0.2 (#1070)

Code
* Performed code refactoring

PiperOrigin-RevId: 684295272
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@yukawa