Hi, I found out why the AUR bazel package didn't work for me: the problem was that ~/.bazelrc needs to point to %workspace%:/opt/bazel/base_workspace/ (as explained in the comments here: https://aur.archlinux.org/packages/bazel/). So now everything works and the PKGBUILD is cleaner :).
One more question: is there a recommended approach to automatically update the revision / commit number of the package? Or is it not necessary to update this? I've seen some packages that simply put a note to not flag the package as out of date. Cheers, Pieter 2015-11-11 3:02 GMT+01:00 Pieter ROBYNS <pieter.rob...@uhasselt.be>: > Hi Anatol and Eli, > > Here are some improvements I made: > - Correctly clone protobuf submodule > - Moved basel build to build() section > - Use tmp file inside build directory > - ./configure in build > - Limit bazel usage to 2 jobs > > So now most of the problems are solved :)! I have added the package to the > AUR. Hopefully it will work for other people as it did on my machine. Maybe > tomorrow I will try to install the package on a fresh Arch install just to > be 100% sure. > > As for the bazel in AUR vs a custom bazel: when attempting to compile with > the AUR bazel I get: > --- > % bazel build --jobs 2 -c opt > //tensorflow/tools/pip_package:build_pip_package > ERROR: Loading of target '//tools/jdk:SingleJar_deploy.jar' failed; build > aborted: no such package 'tools/jdk': BUILD file not found on package path. > ERROR: Loading failed; build aborted. > > % bazel version > Build label: head (@non-git) > Build target: > bazel-out/local_linux-fastbuild/bin/src/main/java/bazel-main_deploy.jar > Build time: Tue Nov 10 10:15:42 2015 (1447150542) > Build timestamp: 1447150542 > Build timestamp as int: 1447150542 > --- > > I think this error is a bit strange, since the directory does contain a > BUILD file. The "custom" bazel can find it: > --- > % bazel build --jobs 2 -c opt > //tensorflow/tools/pip_package:build_pip_package > ** snip, build ok > > % bazel version > Nov 11, 2015 2:26:53 AM > com.google.devtools.build.lib.analysis.BlazeVersionInfo logVersionInfo > INFO: Blaze version info: Build label: head (@125b349) > Build target: > bazel-out/local_linux-fastbuild/bin/src/main/java/bazel-main_deploy.jar > Build time: Wed Nov 11 01:06:28 2015 (1447203988) > Build timestamp: 1447203988 > Build timestamp as int: 1447203988 > --- > > So it seems that there is a slight difference in build timestamp. I will > investigate further tomorrow and contact the maintainer of bazel if > necessary. Maybe it's just a configuration issue. > > > Cheers, > Pieter > > > 2015-11-10 19:37 GMT+01:00 Eli Schwartz <eschwart...@gmail.com>: > >> On 11/10/2015 12:59 PM, Pieter ROBYNS wrote: >> > Hi Eli, >> > >> > Thanks for your feedback! My responses can be found below. >> >> You're welcome. >> >> > Yes you are right, it seems the bazel versions do match but for some >> reason >> > the one from AUR didn't work for me. Could be easily solved with a >> > makedepends entry for bazel. >> > >> > So, best not to upload to AUR? I'm okay with that, I learned something >> when >> > making the PKGBUILD and now I have a clean bleeding edge package :). >> >> I didn't say that... >> Upload it to the AUR whenever you feel confident you have done the best >> job you can with the PKGBUILD. >> Make use of feedback to improve it where possible. >> If it needs to use a custom build of bazel, then do that. If you can >> safely use the pre-existing AUR package, then someone's already done the >> work for you, which is always better! >> >> I don't see why the AUR package for bazel wouldn't work... >> ... maybe you caught it while the AUR package was bumped to 0.1.1 -- it >> was reverted a couple hours later. >> It's the same source code and the same build otherwise. >> >> Gremlins? >> >> > I've found an option in bazel to limit the amount of parallel jobs; >> perhaps >> > that's fine as well. >> >> For Makefiles, there is a default MAKEFLAGS="-j2" in makepkg.conf, which >> helps people customize things. >> I guess you can just pick a sane default. :thumbsup: >> >> > Hehe, I just followed Google's build instructions and I thought it >> wouldn't >> > matter since their script creates temporary files in /tmp/ anyway. I >> agree >> > that doing it in the build directory of the package is cleaner. >> > >> > Thanks again for your advice! >> > >> > >> > Kind regards, >> > Pieter >> > >> >> Hmm. I wonder why *they* scatter files around /tmp. One extra thing for >> them to clean up manually... >> >> -- >> Eli Schwartz >> > >