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
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
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
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
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
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
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
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
With this commit macOS GitHub Actions start running on 'macos-14'
runner, which now runs on Apple silicon.
One observable change is that 'Mozc_arm64.pkg' from 'build_arm64' job
is a bit smaller because we no longer need to build Qt6 as universal
binaries.
Python version is also updated as Python 3.9 is not available for
'macos-14' runner right now.
Closes#868.
PiperOrigin-RevId: 603665115
This commit updates 'actions/upload-artifact' used in our GitHub Actions
rules from
actions/upload-artifact@v3
to
actions/upload-artifact@v4.
According to the release note [1], there are several breaking changes
but none of them looks to be hitting us.
[1]: https://github.com/actions/upload-artifact/releases/tag/v4.0.0
#codehealth
PiperOrigin-RevId: 600269936
This commit updates 'actions/cache' used in our GitHub Actions rules
from
actions/cache@v3
to
actions/cache@v4.
According to the release note [1], there seems to be no breaking change.
[1]: https://github.com/actions/cache/releases/tag/v4.0.0
#codehealth
PiperOrigin-RevId: 599384139
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
This is a follow up to e946483fa5 for #801.
Looks like 'build_universal_binary' can take more than 90 mins occasionally.
Let's increase it to 120 mins for now.
PiperOrigin-RevId: 564887983
In most Linux distributions, system-provided Qt6 libraries are supposed to be
built with libstdc++ rather than libc++. This means that mozc_tool also need to
link to libstdc++ to avoid ABI mismatch unless we build Qt6 from the source code
like we do so in macOS and Windows builds. For now, let's assume GCC and
libstdc++ in Linux CI.
Closes#803.
#codehealth
PiperOrigin-RevId: 563670356
This commit updates our GitHub Actions rules to use 'actions/checkout@v4' to
check out source code.
According to the release note [1], there seems to be no breaking change.
[1]: https://github.com/actions/checkout/releases/tag/v4.0.0
#codehealth
PiperOrigin-RevId: 563656358
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 follow up to my commit [1], which enabled GitHub Actions
to upload build artifacts for Windows, macOS, and Linux but not for
Android. This commit is to also support Android.
One interesting requirement for Android is that developers usually need
to build *.so for the following 4 architectures.
- armeabi-v7a
- arm64-v8a
- x86
- x86_64
With this commit, our GitHub Actions rule actually starts building
'libmozcjni.so' for the above 4 architectures, then archives them into
a single zip file and upload it as the final artifact.
[1]: bb50663d5e
PiperOrigin-RevId: 561867498
This is a cleanup after #775.
As Qt6 migration has been successfully completed, let's simplify our
Windows CI by removing build configurations with Qt5.
By doing this, we can start further cleaning up other scripts such as
'update_deps.py' and 'build_qt.py'.
#codehealth
PiperOrigin-RevId: 561083677
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
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
With this commit, Windows build starts using Qt6 by default.
You can still use Qt5 by explicitly specifying Qt5 source archive with
'--qt_archive_path' option in 'build_qt.py'. You can also find Qt5
build status in GitHub Actions.
PiperOrigin-RevId: 553162054
This follows up to bb52df2437.
With this commit we use Ubuntu 22.04 as the reference build environment
for Mozc for Linux and Android.
This commit also updates NDK version from 'r21b' to 'r25c' as otherwise
Android build fails.
Also the default Clang version in Ubuntu 22.04 is '14' thus we do not
need to explicitly set them in 'CC' and 'CXX'.
This is also a preparation of Qt6 migration (#775), as Ubuntu 20.04 does
not have Qt6 in their official repository.
Closes#763.
PiperOrigin-RevId: 552728127
This commits delete src/renderer/unix, which is has also been known as
"Mozc GTK renderer". By removing this we can make it clear that GTK+2
(e.g. `libgtk2.0-dev`) is not necessary to build Mozc in Linux.
#codehealth
Closes#781.
PiperOrigin-RevId: 551780822
This follows up to my previous commit [1], which aimed to update the
ninja binary to 1.11.0 that has a compatibility fix [2] by using
Chocolatey.
It seems that Chocolatey is not stable. Let's use update_deps.py to
download the binary from GitHub.
[1]: c34fd2962e
[2]: 66b05496ff
PiperOrigin-RevId: 551728663
selection_monitor.cc has been a fallback for features built on top of
surrounding text APIs to continue working even when
IbusEngineWrapper::GetSurroundingText() doesn't return correct
anchor_pos.
The way how selection_monitor.cc worked around was to keep monitoring
clipboards via by X11 APIs. However I believe it's time to remove this
workaround. My rationales are:
* Having a runtime dependency on xcb from ibus_mozc is getting more
and more questionable, especially when the industry is heading to
Wayland. There was actually an issue in Ubuntu 21.10 [1] because of
this dependency.
* If an IME API doesn't work well, ideally such an issue should be
addressed in the right component, rather than trying to work around
it in each IME.
[1]: https://bugs.launchpad.net/ubuntu/+source/mozc/+bug/1946969
#codehealth
PiperOrigin-RevId: 551164079
With this commit we can start using C++20 features in Windows build.
There must be no user observable behavior change.
Closes#769
PiperOrigin-RevId: 548581637
By only giving read permission, we can guarantee that running GitHub Actions can never perform unexpected write operations to our repository resources such as modifying git repository and updating issues.
Note that even with this configuration, we can still upload build artifacts and rely on GitHub Actions cache.
PiperOrigin-RevId: 548428394
As the first step to stopping building `Mozc32.msi`, this CL stops uploading `Mozc32.msi` as an artifact of GitHub Actions.
#codehealth
PiperOrigin-RevId: 537191899
Seems that GCC 9.4.0 installed in `ubuntu-20.04` image doesn't recognize `decltype(<member variable>)`.
Let's switch to Clang 12 as the host toolchain in GitHub Actions for Linux and Android as a quick workaround.
PiperOrigin-RevId: 536605776
This is a follow up to e8d211e9f1 for #749.
Putting a line starts with `#` in `run` lines ends up with the following (non-critical) warning for `cmd` shell in Windows. Let's move it outside of `run:` lines to keep the build log cleaner.
```
'#' is not recognized as an internal or external command,
operable program or batch file.
```
There should be no actual behavior change in the build process itself.
PiperOrigin-RevId: 536563466
