This is the first part towards removing the dependency on Docker from
our build instructions for Linux desktop and Android (#1181).
This commit makes it clear that you can build 'libmozc.so' on both Linux
and macOS by the same Bazel command with actually demonstrating it in
.github/workflows/android.yaml
that 'libmozc.so' can be built on both Linux and macOS GitHub Actions
runners.
With above our 'Dockerfile' can stop setting up Android NDK since
'build_mozc_in_docker.md' does not mention Android any more.
This commit is only about the build instructions of 'libmozc.so' for
Android. There must be no difference in the final artifacts.
PiperOrigin-RevId: 729468755
This follows up to our previous commit [1], which introduced
.bazelversion
so that we can centralize where to specify the expected version of Bazel
in our CI and build instructions.
This commit replaces the remaining usage of
bazel
command with
bazelisk
command then explain where the expected bazel version is specified.
This is just a documentation change. There must be no behavior change in
the final artifacts.
[1]: 8d704f0f82
PiperOrigin-RevId: 728118770
As Mozc is not compatible with Bazel 8.0 yet, let's
* pin Bazel version to Bazel 7.4.1 in GitHub Actions.
* clarify that Bazel 8.0 is not supported in the build instructions.
PiperOrigin-RevId: 698388242
We need to keep GoogleJapaneseInputController as an alias of MozcImkInputController for backward compatibility. This will be removed in the future when all clients are migrated to the new name and performed relogin at least once.
#codehealth
PiperOrigin-RevId: 683091904
We no longer need to create a subclass of IMKInputServer since the same logic has been migrated to RendererReceiver.
#codehealth
PiperOrigin-RevId: 683089874
As we are about to complete bzlmod migration (#1002), let's also update
the build instructions to make it clear that "MODULE.bazel" will be the
file to be customized depending on differences in Linux distributions
and packagers' needs.
PiperOrigin-RevId: 680748113
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]: ffc460e0f3
[2]: b92c4fd289
PiperOrigin-RevId: 680747948
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
With this commit 'vcvarsall.bat' (and its variant) are no longer
requires to be executed before running 'build_mozc.py', like
'build_qt.py' has never required 'vcvarsall.bat' (and its variant) [1].
'--vcvarsall_path' option, which is available in 'build_qt.py' [2],
is also available to explicitly specify a custom path of vcvarsall.bat
as follows.
build_mozc.py --vcvarsall_path=C:\VS\VC\Auxiliary\Build\vcvarsall.bat
Overall this commit should make our build instructions simpler and
easier to keep maintaining.
Closes#923.
#codehealth
[1]: baf418832c
[2]: c777896808
PiperOrigin-RevId: 629293616
This commit upgrades WiX, which we rely on to build Mozc's installer
from WiX v3.14 to WiX v4.0.5 [1].
Unlike WiX v3.14, which we checked out as an xcopy deployment under
src/third_party/wix
with our in-house script update_deps.py, WiX v4 and later will be
installed from NuGet repository with 'dotnet' command [2]. On top of
that we use local installation mode so that a specified version of WiX
can be used in our repository in a side-by-side manner rather than
asking developers to install WiX globally. The WiX version is pined in
dotnet-tools.json
in the repository root [3]. You can run the following command
dotnet tool restore
from any directory in the repository so that the specified version of
WiX can become available, no matter what version of WiX is globally
installed in the system.
To actually run locally installed version of WiX, you can run
dotnet tool run wix
from any directory in the repository.
.wxs file were also converted as follows [4]
dotnet tool run wix convert
then manually cleaned up a bit.
There must be no user observable behavior change in Mozc64.msi.
I have actually confirmed it by manually checking InstallExecuteSequence
table in Mozc64.msi by using Orca [5].
#codehealth
[1]: https://github.com/wixtoolset/wix/releases/tag/v4.0.5
[2]: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet
[3]: https://learn.microsoft.com/en-us/dotnet/core/tools/local-tools-how-to-use
[4]: https://wixtoolset.org/docs/fourthree/
[5]: https://learn.microsoft.com/en-us/windows/win32/msi/orca-exe
PiperOrigin-RevId: 624751431
With this commit macOS build starts using Python virtual environment so
that our build steps can comply with PEP 668 [1].
This is only about the build procedure. There must be no behavior change
in the build artifacts.
#codehealth
[1]: https://peps.python.org/pep-0668/
PiperOrigin-RevId: 621123606
This is a relatively large update with several breaking changes.
- Most of the code in `//base:logging` is now removed.
- Logging calls are now handled by `@com_google_absl//absl/log`. This means:
- Log message formats will change.
- Important: If you have existing log files and run non-release builds (more precisely `!defined(MOZC_NO_LOGGING)`), your files will contain mixed formats after this commit. You may want to remove or rename the existing one.
- Flag deprecations
- `--colored_log`: they're not supported by Abseil.
- `--logtostderr`: this flag had a inconsistent behavior with a google-internal flag of the same name (nor it doesn't make sense for mozc to consolidate the semantics), and is not provided by Abseil.
- Note: There's no longer a way to disable log files in debug builds. A configuration option might be added later if this proves problematic.
The Abseil logging library is packed with many features. It provides out-of-box integration with the Windows debugger and allows you to adjust the verbosity of your logs using command-line flags (e.g., `--stderrthreshold=0` to see all INFO level logs and above). For a full list of features, take a look at their documentation and source code.
PiperOrigin-RevId: 610006013
WiX 3.14 became the latest release of WiX v3, which can now be
downloaded from GitHub [1].
As a consequence, it seems that the previously used download URL is no
longer available. Thus wix314-binaries.zip now needs to be downloaded
from GitHub.
[1]: wixtoolset/wix3@wix314rtm
PiperOrigin-RevId: 609383086
By setting 'configure = True' to 'repository_rule' when defining an
external repository, the repository will be re-evaluated by running the
following command [1].
bazel sync --configure
Hopefully this command can fix most of mysterious build failures due to
stale external repositories and/or build toolchanins, which cannot be
simply fixed by 'bazel clean'.
[1]: 80edda5b7b/site/en/extending/repo.md (L156-L168)
PiperOrigin-RevId: 580265652
This is a follow up to my previous commit [1], which aimed to build
'libmozc.so' for relevant architectures.
Although in the above commit I believe I followed exactly the same step
explained in the Bazel document [2], it seems that artifact files are
not ready to run on the actual Android devices. Perhaps it might be
because the above approach is for those who want to build native
libraries for Android without building an APK, which is somewhat
not-a-major use case and may not be well maintained. This is why I
ended up building a temporary fat APK only to extract native libraries
from it.
Basically what this commit does are:
1. Build a fat APK, which depends on 'mozcjni' cc_library target.
2. Extract native libraries from the APK and zip it as native_libs.zip
The temporary APK used here is completely empty and used only for
building purpose.
The 'package' meta target is updated to point to the native library
build target, which is 'android/jni:native_libs'.
bazel build --config oss_android package
ls bazel-bin/android/jni/native_libs.zip
'.bazelrc' is also updated because Android build starts using the
following options instead.
* --android_crosstool_top=@androidndk//:toolchain
* --fat_apk_cpu=armeabi-v7a,arm64-v8a,x86,x86_64
Dockerfile is also updated because now Android build requires not only
Android NDK but also Android SDK.
This commit only affects Android build target. Other build target
should continue to success without installing Android SDK/NDK.
Closes#840.
[1]: 5a6e457b72
[2]: https://bazel.build/docs/android-ndk#cclibrary-android
[3]: https://bazel.build/docs/android-ndk
PiperOrigin-RevId: 578420951
With this commit macOS and Windows builds switch to Qt 6.6.0 [1], which
contains an important commit for Per-Monitor DPI support in Windows [2]
as discussed in #831.
Note that '-no-feature-systemsemaphore' needs to be removed as otherwise
the build fails in macOS.
[1]: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.6.0/release-note.md
[2]: 5e0d9a077d
PiperOrigin-RevId: 575700086
With this commit, one remaining behavior difference between Mozc
and MS-IME in Windows 11 22H2 will be addressed.
Mozc has had a special no-op rule when switching input focus and the
InputScope specified in the newly focused field is the same as the one
that was previously observed in the same process. MS-IME, on the other
hand, does not have such a special no-op rule and always updates its
input mode upon switching input focus.
For better app compatibility, let's make it compatible with MS-IME's.
Closes#826.
PiperOrigin-RevId: 574371235
Mozc for Windows has been mapping IS_ALPHANUMERIC_HALFWIDTH InputScope
to "Halfwidth Alphanumeric Mode (IME On)" to be compatible with
Microsoft IME 2012. However, recent versions of MS-IME map it to
"Direct Mode", probably to make it more consistent with their
default settings of "Don't use direct input mode" [1].
This discrepancy can result in unexpected user experiences when app
developers assume IS_ALPHANUMERIC_HALFWIDTH is a way to turn off IME
based on recent MS-IME's behavior [2].
Anyway, Mozc's design philosophy has been to emulate MS-IME's behavior
whenever possible. Let's just update InputScope mapping to be
compatible with the latest version of MS-IME.
Closes#818.
[1]: https://github.com/google/mozc/issues/817
[2]: https://github.com/microsoft/terminal/issues/14407
PiperOrigin-RevId: 573458610
With this commit, GitHub Actions for macOS starts building and uploading the
installer for the following 3 CPU architectures.
- x86_64
- arm64
- universal (x86_64 and arm64)
One caveat is that so far we have not figured out how to build Qt6 for arm64 on
Intel mac. As a result, Qt6 binaries in the arm64 installer are built as
universal binaries rather than a pure arm64 binaries. This can be easily
fixed once GitHub start offering GitHub-hosted arm64 macOS runners.
In the build artifacts, it is clear that Universal Binary basically doubles the
installer size.
Closes#801.
PiperOrigin-RevId: 562468629
This is a preparation to support universal binaries for macOS (#801).
With this commit, you can start building Qt6 as universal binaries as follows.
# Build universal binaries
python3 build_tools/build_qt.py --release --confirm_license \
--macos_cpus=x86_64,arm64
Under the hood, '-DCMAKE_OSX_ARCHITECTURES' option is passed to the configure
options of Qt6 [1].
You can also build Intel64 binaries on arm64 Mac as follows.
# Build Intel64 binaries
python3 build_tools/build_qt.py --release --confirm_license \
--macos_cpus=x86_64
A known limitation is that building arm64 binaries on Intel64 mac does not
currently work though.
If '--macos_cpus' is not specified, Qt6 binaries will be built for the host CPU
architecture as it used to be.
[1]: https://doc.qt.io/qt-6.5/macos-building.html#step-2-build-the-qt-library
PiperOrigin-RevId: 562439404
Since 'ibus_config.textproto' was originally introduced [1], we have
added several new fields there [2][3][4].
Let's update configurations.md to comment on what setting is available
from which version.
#codehealth
[1]: 9ba59b64d5
[2]: 467a91c5b2
[3]: 96e8c8782b
[4]: 65a5d1f7bd
PiperOrigin-RevId: 560722690
This is a follow up to 4a77c6a7a8,
which introduced the 'MOZC_IBUS_CANDIDATE_WINDOW' environment variable
per discussion at #637.
With this commit, 'ibus_config.textproto' can be used to customize
when to use 'mozc_renderer' instead of relying on the environment
variable.
To disable Mozc' candidate window:
mozc_renderer {
enabled : False
}
To use Mozc' candidate window for X11 sessions and KDE Wayland
sessions:
mozc_renderer {
enabled : True
compatible_wayland_desktop_names : ["KDE"]
}
If there is no settings, it will be interpreted as if there was the
following settings.
mozc_renderer {
enabled : True
compatible_wayland_desktop_names : ["GNOME"]
}
While environment variable 'MOZC_IBUS_CANDIDATE_WINDOW' is still
supported, it is considered to be deprecated and may be removed in a
future version of Mozc.
PiperOrigin-RevId: 560186593
With this commit, macOS Bazel build starts linking to Qt6.
Here are things needed to use Qt6:
* Qt6 uses 'libexec' rather than 'bin' to host tools like 'uic'.
* Qt6 uses 'Frameworks/QtCore.framework/Versions/A' rather than
'Frameworks/QtCore.framework/Versions/5'.
PiperOrigin-RevId: 558715583
As discussed in #431, it'd be safer to fall back to IBus' own candidate
window for Walyand sessions by default, as whether our 'mozc_renderer'
can be shown at the right place is not guaranteed.
For those who really want to try out our 'mozc_renderer' can still do
so by setting 'MOZC_IBUS_CANDIDATE_WINDOW=mozc', which was introduced
by 4a77c6a7a8 in #637.
This change is also supposed to a give better dark mode support for
Wayland sessions, as 'mozc_renderer' doesn't officially support dark
mode yet. Closes#792.
PiperOrigin-RevId: 558193718
With this commit, Linux build starts linking to Qt6.
Here are things needed to use Qt6 in Ubuntu 22.04.
* Qt6 uses 'libexec' rather than 'bin' to host tools like 'uic'.
* Qt6 requires 'libgl-dev' in Ubuntu 22.04.
* Ubuntu 22.04 uses Qt 6.2.4, where you cannot use pkg-config for Qt6
due to QTBUG-86080 [1]. This commit works around it by injecting
files like Qt6Core.pc files with 'PKG_CONFIG_PATH' environment
variable.
[1]: https://bugreports.qt.io/browse/QTBUG-86080
PiperOrigin-RevId: 558016590
As of Qt 6.5.2, only macOS 11 and later releases are supported [1].
To make Qt6 migration happen (#775), this commit updates the macOS
deployment target to 'macOS 11'.
[1]: https://doc.qt.io/qt-6/macos.html#supported-versionsCloses#786.
PiperOrigin-RevId: 557172153
This is a preparation of Qt6 migration in mac (#775).
With this commit, Ninja 1.11.0 executable will be downloaded into
src/third_party/ninja
not only for Windows but also for macOS, as Qt6 officially supports only
ninja as the cmake generator.
PiperOrigin-RevId: 554852739
