`build_bin=1 make extra` fails

[felixonmars]

Updated 37 files from 14 packages in '/home/felix/projects/arch/community/plum/trunk/src/plum-0.0.20180508-extra/output'
make[1]: Entering directory '/home/felix/projects/arch/community/plum/trunk/src/plum-0.0.20180508-extra'
rime_deployer --build /home/felix/projects/arch/community/plum/trunk/src/plum-0.0.20180508-extra/output
make[1]: *** [Makefile:28: build] Error 1

rime_deployer exits with error code 1 immediately.

[lotem]

making binaries requires preset packages to be also present. do make all instead or just package the extra source files if you wish to split preset and extra.

I will change the Makefile to avoid the failure. But here are reasons why it doesn't work:

Only those input schemas listed in default.yaml:/schema_list will be built and made available to user by default. They all belong to the preset make target. That's to say even when you do build_bin=1 make all, none of the extra input schemas are built into binary.

IMHO the purpose of packaging binaries is to make IMEs enabled by default settings work out-of-the-box. If an extra input schema requires user to manually enable, then it's probably okay to build on demand. Debian packagers split librime-data into separate packages by input method, and build binaries for each with a modified build script. This sounds good because user can choose individual packages they need. However, installing ALL binaries for extra input schemas would be too much for most users.

Again, preinstalled data files are only meant to offer good out-of-the-box experience. I wouldn't object if you package only the preset target with make && make install. Anyway, /plum/ is itself a package manager for installing latest Rime data packages from GitHub.

[lotem]

Caveat: plum always fetches latest packages. if the package is reproduced from source code, incompatible future changes can be introduced. It is still safe to fetch latest packages today but I've created a new release at rime/brise with all packages' source tree in the tarball.

[lotem]

BTW, are you going to name the package plum? I’m not sure of taking that name from other/future projects that may deserve it better. Unless you’re sure nobody would be interested in using the name, rime-data or librime-data looks good enough to me.

[lotem]

Updated Makefile via https://github.com/rime/plum/commit/b1097e1bbc7cfe50e94c99310ad4395a784759bf Deprecated the build_bin variable, and created new make targets preset-bin, all-bin, minimal-bin.

[felixonmars]

Will future releases of plum still create releases at rime/brise? BTW, the brise doesn't build here:

no_update=1 make -C plum OUTPUT=/build/brise/src/brise/output all build
make[1]: Entering directory '/build/brise/src/brise/plum'
rm -rf /build/brise/src/brise/output > /dev/null 2>&1 || true
rime_deployer --build /build/brise/src/brise/output
bash /build/brise/src/brise/plum/scripts/install-packages.sh :all /build/brise/src/brise/output
make[1]: *** [Makefile:28: build] Error 1
make[1]: *** Waiting for unfinished jobs....
Found package: bopomofo
ERROR: update-package.sh: not a repository: /build/brise/src/brise/plum/package/rime/bopomofo
make[1]: *** [Makefile:19: all] Error 1
make[1]: Leaving directory '/build/brise/src/brise/plum'
make: *** [Makefile:19: all] Error 2

I'm also not sure if the new directory structure of plum-built binaries will work with the current ibus-rime/fcitx-rime :/

[lotem]

Waa~ I excluded all the .git directories when archiving. What to do? Can I include .git in the source tarball? // Edit: it was my fault. I tested the package under a subdirectory of a git clone. Therefore git commands found it a git repository. Looks I should work around the error in the script.

I only want to update brise for the last time before introducing new syntax described here https://github.com/rime/home/wiki/Configuration I don’t know how you package software for Linux distos but in case someone use automated script watching rime/brise this intents to give them a chance to release something without putting efforts to rime/plum.

The built binaries are found and used by librime. It’ll work as long as the same or newer version of librime is used than the version used to build the binaries.

[lotem]

@felixonmars: retagged brise-0.38

[felixonmars]

Thanks! The new brise built fine here. One more question is that it seems the bin files are always built again into ~/.config/fcitx/rime/build even when they are present in /usr/share/rime-data/build/.

Do you think that distributions should build the snapshot themselves in the future? I am still not sure yet...

[lotem]

I know. There is a bug report https://github.com/rime/librime/issues/197#issuecomment-379124399

But as I observed, yaml files and prism.bin files are always rebuilt while the shared copies of table.bin and reverse.bin can be reused. It still make sense to include the latter two which are more expensive to build. If you like you can exclude yaml and prism.bin files to save bandwidth for the moment. It’s also fine to keep them in hope of a future librime update could make them usable.

Why rebuilt: after introducing cross file reference to Rime’s YAML syntax, it’s no longer possible to quickly detect whether a rebuild is needed on startup by checking changes to a single YAML source file. Instead I now save the last write time of all referenced source files in the built YAML file. When a shared copy is installed instead of built in place (rime_deployer —build /usr/share/rime-data), the file’s last write time properties has changed since it was built. I don’t have a quick fix in librime. Build binaries with a post install script is the only solution. At least it make user wait while installing, not after.