Ports metasequoiaime/MSIME-Windows#153 onto the consolidated repository. That pull request was written against the six-repository layout: it edited product-ci.yml, which no longer exists, and re-pinned Server, UiHtml and Installer, which are directories now.
Three of its pinned commits had not reached this repository at all. The consolidation took each source repository at its main, and Server, UiHtml and Installer each landed two more commits afterwards, so dropping the pins as merely obsolete would have silently dropped the work the pull request exists to consume. The two substantive ones are ported here: Server drops its vendored miniaudio.h and builds against the engine's MetasequoiaIme::VoiceCapture, and the installer collects helpcodes from the engine. UiHtml's was an engine gitlink bump, which one submodule resolves on its own.
The engine is pinned to d0dc0c2b rather than to the b7c799ef that pull request named. b7c799ef predates 403b4a4d, which is what this repository pins today and is the commit that added pagination to the settings dictionary contract, so taking the pull request's pin verbatim would have reverted a contract main already depends on and stripped offset, limit and hasMore back out of the generated web bindings. d0dc0c2b is the engine's main and is the same commit the dictionary release declares as its source, so the code and the data now name one commit.
The helpcodes moved into the engine, so MSIME-HelpCode stops being a product input: the gitlink that pins the contracts pins the tables too. product-lock.json is down to the engine and the dictionary release, and the dictionary itself now ships from MSIME-Engine. Its manifest states which commit built the data and whether that tree was clean, and the lock verifies both, so matching digests can no longer stand in for a source nobody can rebuild from. The retired MSIME-Dict repository stays valid for the one tag that shipped from it and nothing else.
The release job that packages now checks out submodules, because the helpcodes it collects live in one.
The product README was under windows/ after the move, but it was never a component readme: it is the download page, the feature guide and the contribution guide for the whole product, so it goes back to the root and windows/ gets a real component readme.
AGENTS.md at the root now carries the repository map, the component boundaries that used to be cross-repository rules, and the release process, since the scripts that process drives live at the root. The component files keep what is genuinely theirs and say which paths they are relative to. References that named sibling repositories now name sibling directories, and the lock documentation records that Server, the pages, the GUI framework and the installer are no longer inputs to pin.
#22 added Provision dictionary data and Test steps to ci.yml, so the section
saying CI never runs the suite was inverted the moment that landed. ctest runs
on every PR and a failing assertion turns the build red.
The part worth writing down is what #22 had to set up to make that work: the
tests read the real msime.db, others.db and english.db from the data root plus
the full five helpcode schemes, none of which this repository carries. A local
run without that data does not fail with a missing-file error, it fails with
empty candidate sets and assertion messages that read like logic bugs, so the
section now says to check the data root before debugging a failure. Also
records METASEQUOIA_IME_DATA_DIR as the override.
Restores BUILD_TESTING to its previous value after the engine subdirectory
instead of hardcoding ON, the same save-and-restore this file already does with
BUILD_SHARED_LIBS around cpp-pinyin. #26 put the flag back with a literal ON,
which would quietly re-enable this repository's own tests/ for anyone who
configured with -DBUILD_TESTING=OFF.
CMakeLists.txt hardcoded ${CMAKE_SOURCE_DIR}/build/vcpkg_installed in three places, for the WebView2
loader import library and two include paths, so the binary directory had to be literally named
build. The sqlite3 copy nearby already used ${CMAKE_BINARY_DIR}; the other three now match it.
The symptom is this repository's own vcpkg-release preset, whose binaryDir is build-release:
cmake --preset=vcpkg-release fails to link MetasequoiaImeSettings with LNK1181, and so does
scripts/lcompile-release.ps1, which uses it.
CI now builds into build-release. The two expressions resolve to the same path when the directory
happens to be called build, so leaving CI alone would make this a rename that proves nothing.
Rebased onto #22, whose dictionary provisioning and ctest step are kept as they are.
The section heading still said CI runs none of the tests, which contradicted
the body right under it: the target is configured and compiled on every run,
and a compile error in tests/src turns CI red. Only the running is missing.
Adds the two facts the section was short of. tests/CMakeLists.txt:78 registers
an add_test entry, so ctest has something to run rather than an empty set, and
the Configure step passes neither -DBUILD_TESTING=OFF nor anything else that
would drop the target, which is why it is always built.
Replaces "手动跑一次测试工程" with the command that actually works against the
build directory CI and the local scripts use.
* chore: consume the engine as a library and stop prepare_env clobbering the build
The engine submodule was pinned at a197746, eight commits behind the engine's
main branch and older than the commit that first gave the engine a CMakeLists
of its own. That is why this repository listed the engine's translation units
by hand: at the pinned commit there was no target to link against. There is
one now, and Apple and Linux already consume it, so do the same here.
- advance the engine submodule from a197746 to 8cc306c
- add_subdirectory the engine and link MetasequoiaIme::Engine from the server,
the dictionary replay tool and the settings executable, dropping the two
hand-maintained source lists
- point the engine and msimeui submodule URLs at MSIME-Engine and MSIME-UI,
and update the README, which still used the pre-rename repository names
prepare_env.py, which the README tells every new contributor to run first,
overwrote four tracked build files from templates under scripts/config_files
that had fallen years behind:
- CMakeLists.txt was replaced by a 147-line copy of what is now a 400-line
build, dropping opencc, cpp-pinyin, msimeui, settings and the panels
- tests/CMakeLists.txt was replaced by an unrelated generic WinCppTemplate
- CMakePresets.json lost the vcpkg-release preset that llaunch-release.ps1
needs
Running the documented first build step therefore broke the build. The script
now only writes the two files that are genuinely generated, and rewrites
CMakePresets.json in place instead of copying a stale template over it.
The .clangd generation addressed template lines by index and the indices had
drifted: the Boost path was written over the WebView2 include and the Sciter
path over a comment, leaving clangd unable to resolve the WebView2 headers.
The template now carries named placeholders, and the script fails loudly if
any are left unsubstituted.
Also remove src/sciter. It is a third candidate window backend that no
CMakeLists has referenced for some time; the shipped backends are d2d and
webview2, and those are the only two ui_backend accepts.
* docs: keep the historical checkout directory names in the build steps
The clone URLs had to change, since the old ones only resolved through
GitHub's rename redirect, but cloning without an explicit target would also
have renamed the working directories. MSIME-Windows's AGENTS.md records that
the historical directory names are deliberate: msime-installer's
Prepare-PackageFiles.ps1 expects siblings called MetasequoiaImeServer and
MetasequoiaImeDict, and the release workflow checks the current repositories
out into exactly those paths. Clone into them explicitly instead.
* chore: re-pin the engine at the WIN32_LEAN_AND_MEAN fix
Moves the submodule from 8cc306c to f91cd20. That carries metasequoiaime/MSIME-Engine#14,
which stops the engine exporting WIN32_LEAN_AND_MEAN as a PUBLIC compile definition and so
unblocks MetasequoiaImeSettings, whose WebView2.h include failed with 101 instances of C2146
against the trimmed Windows.h the definition forced on every consumer.
The range also picks up the two dependabot merges the engine took in the meantime: #12 bumps
utfcpp and #13 bumps the pinned action SHAs.
* build(tests): link the engine target instead of listing its sources
The test executable hand-listed the same 41 engine translation units the root
CMakeLists.txt did, and compiled them without NOMINMAX. That went unnoticed
while the pinned engine predated core/key_event.h; now that the engine headers
pull in Windows.h, the min and max macros collide with std::max and the build
fails with C2589 in quanpin_query.cpp.
Linking MetasequoiaIme::Engine fixes it at the source: NOMINMAX is one of the
definitions the engine exports PUBLIC precisely because it changes the declared
API surface.
* docs(agents): correct the tests wiring and describe the new prepare_env
Two sections went stale or were inaccurate.
The tests section said the root CMakeLists.txt does not reference tests/ at
all. It does: include(CTest) at :8 defaults BUILD_TESTING to ON and :411
add_subdirectory(tests) picks it up, so the test target is configured and
compiled on every CI run. This PR proved it from the other side, by breaking
the test target's build with a NOMINMAX regression that CI caught. The real
gap is narrower and still worth the warning: ci.yml has no ctest step, so the
executable is built and never run.
The generated-files section described prepare_env.py copying templates over
CMakeLists.txt and CMakePresets.json by fixed line index. This PR removes that
behaviour, so the section now describes what the script actually does.
MSIME-Windows carries an AGENTS.md that opens by saying it governs the whole project, but it is
invisible from here. This points at it and records what is specific to the Server.
Two of the entries are defects rather than conventions, written down because they are load-bearing
until someone fixes them. The binary directory has to be literally named build, since CMakeLists.txt
hardcodes CMAKE_SOURCE_DIR/build/vcpkg_installed in three places for the WebView2 loader; the repo's
own vcpkg-release preset sets binaryDir to build-release and therefore does not link. And the 34
test sources under tests/ are a separate project the root CMakeLists.txt never references, with no
ctest step in CI, so a green check says only that the Server compiles.
Lu Fan(SonnyCalcr)