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