Arch Linux User Repository

If you're getting compilation errors, please delete your Bazel cache (~/.cache/bazel by default).

If you're getting compilation errors, please delete your Bazel cache (~/.cache/bazel by default).

@LetMeByte Yeah, ccache et al still remain largely incompatible with Bazel. I think the obvious and even easier solution to this would be to add BUILDENV=(!distcc !ccache) in the PKGBUILD so as to explicitly disable both of them, even if the user has manually enabled them in makepkg.conf. Is that what you meant by "setting a compatible toolchain"?

The funny thing is, more than one times in the past I've proposed this solution to other AUR maintainers for them to use in their packages in order to fix this exact same issue, but apparently I failed to ever realize it could also be used to solve the issue in my own package as well :P

Anyway, I'll do it in the next update.

Building mozc(-ut) with distcc/ccache installed results in various errors.

The problem is caused by distcc/ccache exporting their own versions of GCC and Clang, check with which gcc or which clang.

The temporary fix is to disable the corresponding options in /etc/makepkg.conf, or just setting the CC environment variable to the standalone version of GCC or Clang:

export CC=/usr/bin/gcc or export CC=/usr/bin/clang

UPDATE: @Nocifer: Thank you for the quick response, the solution you suggested is definitely the best way.

@Nocifer

Thank you for the highly detailed comment and the untold (but appreciated) hours of work you put in for little old me.

As previously mentioned I am not overburdened with an excess of brain cells, so I won't try to "[delete] the package cache" because I will somehow manage to rm rf --no-preserve-root / or chmod -x chmod or something, and I need this laptop for work. Instead, I will continue to daily drive my laptop and report back after a couple of updates.

Of couse, I have no doubt that your newfound expertise has not been misplaced and my issue has been resolved, so once again I'd like to extend my thanks.

After digging around a bit I believe I've found the culprit. Turns out that whenever the PATH is modified, Bazel will unconditionally invalidate its cache, even if the newly assigned PATH value is the same as before. I've changed the PKGBUILD to use a Java-specific variable that allows Bazel to find and use Java 11 without touching the PATH, so now the cache works as intended.

The bad news is that the first time you try to rebuild the package using the new PKGBUILD, from Bazel's perspective the PATH will once again be modified (from the previously used "/usr/lib/jvm/java-11-openjdk/bin/:$PATH" to the default PATH) so the cache will once again become invalidated; but on the next and subsequent rebuilds it will not, and from then on only the modified files will need to be recompiled on package updates.

The good news is that with this next update I was already planning to replace mozc-ut-common with mozc-ut, which means that Bazel will need to do a full recompile anyway, regardless of the cache issues, because mozc-ut is a completely new package. So one way or another, you guys won't be spared the full recompile. Oh, sorry, this was supposed to be the good news :)

@asday, thanks for taking the time to mention this issue, it ended up becoming the catalyst for an arguably very good improvement (not to mention that I've had the opportunity to learn some interesting things about how Bazel works internally). Also, if you wish to test and verify that the cache now works properly, then as soon as you finish with the update you can force a rebuild by deleting the package cache and then reinstalling Mozc - hopefully, this time the compilation step should only take a handful of seconds at most (because nothing will be recompiled).

EDIT: Unfortunately, TIL that the replaces field in the PKGBUILD apparently does not work for AUR packages, and the only way to automatically replace an installed AUR package is to merge it into its replacement. But I'd already pushed the new updates before I learned that, so it's going to be two full recompiles in the space of a few days (one for mozc-ut-common now, and one for mozc-ut when the merge goes ahead). What fun.

@asday This package normally receives an update once a month, i.e. when the UT dictionary puts out a new version, and along with UT it pulls in the latest monthly updates to Mozc. These last couple of months have been an exception to the rule, with 2 or 3 updates per month, some of them because of Mozc changes that introduced incompatibilities and/or build failures and required an update to address them, and some of them because for whatever reason there were multiple versions of UT released within a single month.

The problem is that, even when only the UT dictionary is updated, the package still requires recompilation because the way things currently work, the dictionary file is not loaded externally by Mozc but must rather be compiled into the Mozc binary itself - i.e. it's not a matter of simply updating the dictionary file and calling it a day.

As for the recompilation of the dependencies, which is mainly about protobuf: as far as I can tell by looking into it just now, it has long been kind of a pain for Bazel users (see e.g. here). You're right that it shouldn't be recompiling on each and every update of Mozc (I hadn't noticed it myself because on my system the whole process takes less than a couple of minutes to finish, so it never bothered me enough to make me look into what exactly it's doing when compiling) but to be completely honest with you, I have no idea why it does so. Maybe it's the way Bazel is set up and called from within the PKGBUILD, or maybe the build rules provided by Mozc are not written properly, or maybe it's some weird quirk of Bazel that needs to be identified and dealt with, or maybe it's something else entirely.

I'll try to look for a solution in the next few days, but I can't make any promises because Bazel is a terribly convoluted tool and I doubt I'll have much luck without seriously investing myself into learning its ins and outs. So for the time being, as tiring as it is for you and your laptop, you'll unfortunately have to bear with these huge updates :/

Good morning.

I regularly receive updates for this package, and installing them involves compiling for maybe a half hour and completely kneecapping my laptop while compiling. This makes it highly inopportune to update my laptop as I'm generally noticing there are updates available while I'm using it.

I notice that while it's compiling, it's compiling things such as protobuf, which I believe to be some library that is highly reuseable, and quite stable, thus unlikely to require recompilation every few days.

It would be nice if I didn't have to recompile the universe every couple of days. Is there some way to cache the built objects? Is there a reason they require building every time instead of being shared objects? Why does this package require updating so often - is it simply a dictionary update? If so, why is that not a simple data file change rather than something requiring recompilation? Am I even asking any of this in the right place?

Please do note that I am very very stupid, so I may have trouble understanding replies that assume my knowledge of a compiler toolchain or bazel or what have you.

Thank you.

That's because of the newly updated GCC toolchain. Just delete your Bazel cache folder and it should work.

~~~ Cannot build package ~~~

ERROR: /home/atri/.cache/bazel/_bazel_atri/e1bccde7c1bd24c3c95cbf2d98859651/external/com_google_protobuf/BUILD:155:11: Compiling src/google/protobuf/io/zero_copy_stream.cc [for host] failed: undeclared inclusion(s) in rule '@com_google_protobuf//:protobuf_lite':
this rule is missing dependency declarations for the following files included by 'src/google/protobuf/io/zero_copy_stream.cc':
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stdarg.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stdint.h'
INFO: Elapsed time: 9.264s, Critical Path: 2.43s
INFO: 11 processes: 10 internal, 1 linux-sandbox.
FAILED: Build did NOT complete successfully
==> ERROR: A failure occurred in build().

Thanks @Nocifer, the package builds successfully.

@evgfilim1 Believe it or not, for the last couple of hours or so I've been unsuccessfully trying to incorporate these two --sandbox parameters you mentioned.

For one, if the specified paths do not already exist (or in other words, for this particular case, if the .ccache folder is missing because ccache isn't installed or hasn't already been used at least once) bazel will complain and fail the build.

Furthermore, even when the paths do exist and I can build successfully on my normal system, I can't for the life of me seem to build inside a chroot - no matter what I've tried, bazel will always complain about not having rw access to one path or another and proceed to fail the build.

I'm not sure if it's my incompetence or if bazel was simply not built to work with a tool like makechrootpkg, but the fact is that I need to be able to build Mozc inside a chroot, and I need to be able to do that in an automated and deterministic way (i.e. no removing these parameters from the PKGBUILD just for test-building in the chroot and re-adding them before I publish the package).

So with that in mind, and also because ccache is rarely worth the effort IMHO (and hence all this trouble), for the time being I will not add these parameters to the PKGBUILD. If and when I manage to find a working solution for using them alongside makechrootpkg (or if someone else provides me with one) I will add them in a future update.