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 <[email protected]>: > 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 >
