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

[Pieter ROBYNS]

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.robyns at 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 <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
>>
>
>