[aur-general] RFC: PKGBUILD for tensorflow-git

Pieter ROBYNS pieter.robyns at uhasselt.be
Wed Nov 11 02:02:44 UTC 2015

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
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:
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
** 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:
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.


2015-11-10 19:37 GMT+01:00 Eli Schwartz <eschwartz93 at 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

More information about the aur-general mailing list