librime: the C++ core, and the twenty-five frontends you have to choose between

Nobody installs librime directly, so the first decision is a frontend

The engine ships as a library, and the frontend list is the part a new user actually reads. Three are official: ibus-rime for IBus on Linux, Squirrel for macOS, and Weasel for Windows. The community list is far longer and spans desktops as well as terminal editors and shells, with coc-rime and rime.nvim and fcitx5-ui.nvim for Vim, emacs-rime for Emacs, zsh-rime, tmux-rime, pyrime for Ptpython and rl_custom_rime for Readline. Android and iOS have Trime, YuyanIme, fcitx5-android and Hamster, and My RIME puts it on the web.

One entry in the plugin list shows the licensing boundary. librime-legacy is marked deprecated and described as holding GPL-licensed code, while the engine itself is BSD-3-Clause. Keeping a product BSD-clean therefore means leaving that module out, not merely ignoring it.

So the practical sequence is: choose the frontend for your platform, install that, and only build librime yourself if you are writing a frontend or need a plugin that no packaged frontend ships.

Linux builds with make, and every other platform has its own document

The Linux path is two commands:

make
sudo make install

Everything else is delegated. macOS and Windows are pointed at README-mac.md and README-windows.md, and the repository carries the scripts those documents lean on: build.bat, env.vs2019.bat, env.vs2022.bat and an env.bat.template, plus install-boost.bat and install-boost.sh for the Boost requirement.

The dependency list explains why the extras exist. A C++17 compiler and cmake>=3.12 are the floor, then libboost>=1.74, libleveldb, libmarisa, libopencc>=1.0.2 and libyaml-cpp>=0.5, with libglog and libgtest optional.

Note what is not required. The preset vocabulary lives in the separate rime-essay project, and configurations are installed with plum.

The Docker image pulls plugins by owner and name, including a deprecated one

The Dockerfile is the shortest complete recipe the repository offers. It starts from debian:12.15-slim, installs the build dependencies including liblua5.4-dev for the Lua plugin, copies the checkout into /librime, and then installs plugins by passing owner and repository names to a script:

bash install-plugins.sh \
  rime/librime-charcode \
  hchunhui/librime-lua \
  lotem/librime-octagram \
  rime/librime-predict

That list is a useful default and also a snapshot with a date on it. librime-charcode appears here while the plugins section marks it deprecated, and the build therefore pulls a module the project has retired. If you copy this line into your own image, check each entry against the current plugin list first.

The same script is what a local build would use, and `plugins/` exists in the tree for the results. Nothing in this path is version pinned, so an image rebuild can pull a different plugin than the one you tested.

Logging and tests are on in the image, the static library is off

Five CMake options decide what the Docker build produces:

cmake -B build -G Ninja \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DENABLE_LOGGING:BOOL=ON \
  -DBUILD_TEST:BOOL=ON \
  -DBUILD_STATIC:BOOL=OFF \
  -DBUILD_SHARED_LIBS:BOOL=ON

Logging on and a shared library on is a sensible combination for a container you intend to debug. Turning the static build off is the consequential one, since anything embedding librime by linking a static archive has to rebuild with different options.

Tests are built in the image rather than skipped, and the last stage runs them:

ctest --test-dir build --output-on-failure

So a container build that succeeds has already built the tests and executed the suite. That is a slower image build and a faster answer to the question of whether a change broke anything.

The Makefile picks its prefix from uname, and macOS writes into the checkout

Installation paths are decided by operating system detection rather than configuration, which is worth reading before the first `sudo make install`. `OS_NAME` comes from `uname`, and each branch sets `prefix` differently: macOS uses `$(RIME_ROOT)/dist`, Linux uses `$(DESTDIR)/usr`, FreeBSD and OpenBSD use `/usr/local`, and a Termux build is detected by looking for `/data/data/com.termux` in `PREFIX`.

The macOS branch also sets two environment values before anything else runs: `SDKROOT` is filled in from `xcrun --sdk macosx --show-sdk-path`, and `MACOSX_DEPLOYMENT_TARGET` defaults to 10.15. Setting `BUILD_UNIVERSAL` switches `CMAKE_OSX_ARCHITECTURES` to `arm64;x86_64`, so a universal build is one variable rather than a second machine.

The consequence for macOS is that the install target sits inside the working tree, while on Linux the same command writes into system directories. Boost gets special handling too: when `BOOST_ROOT` is set, the Makefile passes `-DBoost_NO_BOOST_CMAKE=TRUE` with that root, bypassing CMake's own Boost detection.

clang-format runs with -Werror and skips everything inside plugins

Formatting is enforced by a make target, not left to reviewers. The `clang-format-lint` target prints the tool version and then pipes the source list through clang-format in dry-run mode with warnings treated as errors:

xargs clang-format -Werror --dry-run

The file list comes from `RIME_SOURCE_PATH`, which is `plugins sample src test tools`, filtered to `*.cc` and `*.h` and excluding paths matching `plugins/*/*`. That exclusion is the detail worth noting: third-party plugin checkouts are exempt from the project's style, so a failing lint almost always means your code rather than a plugin.

When it does fail, the target prints a message telling you to run `make clang-format-apply`, which is the same pipeline with `-i` instead of the dry run. Parallelism is automatic unless you define `NOPARALLEL`: the job count is one more than the processor count from `nproc` (or `getconf`, or a fixed 8).

The behaviour you configure lives in YAML schemas, not in the C++

The features list describes an engine whose interesting surface is declarative. Rime input schema is described as a DSL in YAML syntax, intended for trying out input method designs quickly. Spelling Algebra is named as a mechanism for creating variant spellings and singled out as useful for Chinese dialects. Traditional Chinese support is native, with conversion to Simplified and other regional standards handled by OpenCC, and chord typing on a generic Qwerty keyboard is supported, which is what combo-pinyin builds on.

Around that sit three separate projects you will need: plum as the configuration installer, rime-essay as the preset vocabulary, and SCU for editing Squirrel's configuration. None of them is in this repository.

For a frontend author, the practical reading is that C++ work here means engine behaviour and plugins, while everything a user experiences as an input method is a schema file. Reading the schemas is the fastest way to understand what the engine will do with a keystroke.

1.17.0 in June, a nightly tag in October, and plugins that carry their own licences

Release state is easy to read here. The list holds 1.16.1 from 2026-01-20, 1.17.0 from 2026-06-06 and a nightly build tagged latest from 2026-10-27, and the last push was on 2026-10-27 with master as the default branch. Packaging status is tracked externally through repology, so distribution packages can lag the tags without the repository saying so.

The licence picture needs two layers. librime itself is BSD-3-Clause, and the credits name the licence of each dependency: Boost under the Boost Software License, google-glog, Google Test and LevelDB under BSD-3, marisa-trie under BSD-2 with an LGPL 2.1 option, OpenCC under Apache 2.0, and yaml-cpp under MIT. Plugins are separate projects with separate terms, and the deprecation note on librime-legacy mentions GPL-licensed code.

Version bumps go through a bump-version.sh script and the changelog is generated with git-cliff through cliff.toml, so the release trail is machine written.

Editorial conclusion

librime suits someone building an input method frontend, or picking one, who wants the schema layer and dialect support to be their own rather than a vendor's. It is a poor fit as a library to drop into an application that merely needs text conversion, since the packaging is an engine plus data and the plugin set is where the real behaviour lives. Before building, provision Boost 1.74 or higher and OpenCC 1.0.2 or higher, and read the prefix logic in the Makefile before running sudo make install, because on macOS the target directory is inside the checkout.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes