Files
SubMiner/vendor/hachidori/docs/source-build.md
T
sudacode d9fdc7ef6d feat(dictionary): add Hachidori backend support
- Add backend selection, setup gating, Anki integration, and external host support
- Add launcher flags, documentation, packaging, and focused tests
- Open on-demand overlay modals on the first attempt
2026-09-22 00:21:19 -07:00

5.9 KiB

Building a distributed source archive

Each release's hachidori-<version>-<commit>-source.zip includes Hachidori's tracked files, the complete recursive Hoshidicts submodules, and the pinned libavif, libaom and unminified zip.js sources. It contains no Git metadata and does not require access to a private repository. SOURCE_REVISIONS.json records the repository commits and downloaded dependency checksums.

The Chrome upload ZIP contains LICENSE, the dependency notices, SOURCE.txt and SOURCE.json. The source reference names the accompanying archive and its SHA-256. Publish that exact source archive at a public download location and put the location in the store listing before distributing the extension. A private GitHub repository link is not a substitute for that download.

Load the JavaScript source

Extract the archive. Open chrome://extensions, enable Developer mode, choose Load unpacked, and select its extension/ directory. Committed Wasm files are included, so JavaScript development needs no compiler.

Rebuild the dictionary engine

Install Emscripten with C++23 support, CMake 3.31 or newer, and a native build tool. Activate the SDK environment so emcmake, emcc, and em++ are on PATH. Run these commands from the extracted archive's top-level directory:

emcmake cmake -S wasm -B wasm/build -DCMAKE_BUILD_TYPE=Release -DHACHIDORI_PTHREADS=ON -DHACHIDORI_WASMFS=ON
cmake --build wasm/build --parallel
emcmake cmake -S wasm -B wasm/build-idbfs -DCMAKE_BUILD_TYPE=Release -DHACHIDORI_PTHREADS=ON -DHACHIDORI_WASMFS=OFF
cmake --build wasm/build-idbfs --parallel
emcmake cmake -S wasm -B wasm/build-fallback -DCMAKE_BUILD_TYPE=Release -DHACHIDORI_PTHREADS=OFF
cmake --build wasm/build-fallback --parallel
cp wasm/build/hoshidicts-threaded.mjs wasm/build/hoshidicts-threaded.wasm extension/vendor/
cp wasm/build-idbfs/hoshidicts-threaded-idbfs.mjs wasm/build-idbfs/hoshidicts-threaded-idbfs.wasm extension/vendor/
cp wasm/build-fallback/hoshidicts.mjs wasm/build-fallback/hoshidicts.wasm extension/vendor/

The source archive already includes each CMake dependency under third_party/hoshidicts/external/; no submodule checkout is needed.

Rebuild the AVIF encoder

Use the source archive's bundled dependencies to avoid fetching them during configuration:

emcmake cmake -S wasm/avif -B wasm/avif/build -DCMAKE_BUILD_TYPE=MinSizeRel \
  -DFETCHCONTENT_SOURCE_DIR_LIBAVIF="$PWD/third_party/store-sources/libavif" \
  -DFETCHCONTENT_SOURCE_DIR_LIBAOM="$PWD/third_party/store-sources/libaom"
cmake --build wasm/avif/build --parallel
cp wasm/avif/build/avif-encoder.mjs wasm/avif/build/avif-encoder.wasm extension/vendor/

The sources are libavif 1.3.0 at 1aadfad932c98c069a1204261b1856f81f3bc199 and libaom 3.12.1 at 10aece4157eb79315da205f39e19bf6ab3ee30d0. Both libavif's small libyuv subset and libaom's internal dependencies are present in those archives. Other AVIF codecs and external libyuv are disabled by wasm/avif/CMakeLists.txt.

Packaging pins libaom's official release archive. Its source files and executable modes match that commit, while the Gitiles archive endpoint rewrites timestamps on each request and cannot provide a stable download checksum.

zip.js and validation

third_party/store-sources/zipjs/lib/ contains zip.js 2.11.2's editable source; its upstream README.md and package.json describe the library. The release uses its existing dist/zip-core-external.min.js, copied unchanged to extension/vendor/zip.js. No npm install or JavaScript build is needed to restore that shipped file:

cp third_party/store-sources/zipjs/dist/zip-core-external.min.js extension/vendor/zip.js
node test/make-fixture.mjs
node test/node-smoke.mjs
node test/extension-smoke.mjs

See the test guide for the browser suite and its external test dependencies. The packaging command verifies archive checksums and file integrity; it does not compile or run these runtime suites.

These instructions preserve the source revisions and build settings. The historical committed Wasm files do not record the exact compiler version, so they do not establish byte-for-byte reproduction of those binaries. Record emcc --version, cmake --version, build commands and test results whenever publishing newly built Wasm files.

Produce a release pair from a Git checkout

Commit the intended release changes and initialize recursive submodules. With Python 3.9 or newer and Git installed:

git submodule update --init --recursive
python3 scripts/package-store.py --output-dir /tmp/hachidori-store

The command refuses a dirty checkout, reads only committed Git objects, and writes the upload ZIP, source ZIP and SHA256SUMS.txt outside the repository. Its first run downloads only checksum-pinned dependency sources. Pass --cache-dir /path/to/cache to reuse them across machines or offline runs. ZIP paths, timestamps, order and permissions are normalized, giving identical bytes when repeated with the same commit and Python/zlib version. ZIP integrity is checked before checksums are written. Load unpacked from an extracted Chrome ZIP to check the exact staged runtime before uploading it.

CI runs this packaging command and verifies the checksums for every release candidate. The Release workflow supports package-only manual runs by default. Enabling Publish for a manual run requires an existing bare <manifest.version> release tag at the selected commit; the workflow uploads its assets and submits the Chrome package. Pushing <manifest.version> keeps the automatic release path. Both paths publish only after the version, minimum/current Chrome pins, archive integrity, and checksums pass. Chrome Web Store automation requires the service-account secret and the publisher and extension repository variables documented in the publishing guide.