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
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