Hi Eli, Thanks for your feedback! My responses can be found below. 2015-11-10 17:51 GMT+01:00 Eli Schwartz :

...

Dear all,

I have recently created my first PKGBUILD for the tensorflow project which was recently released. This project didn't have a build-from-git AUR package yet, so I figured that it would perhaps be useful to other people as well and therefore I'd like to share my PKGBUILD on the AUR.

Since it is my first PKGBUILD however, could anyone please give some feedback regarding its structure? I also have a few questions:

- The build system used for the project (bazel) appears to require a specific version for the build to succeed (the one in AUR currently is newer and didn't work out of the box) so I had to clone this version of

On 11/10/2015 10:52 AM, Pieter ROBYNS wrote: the

...

build system and compile it temporarily in order to build tensorflow. Is this okay given that the same instructions are given on their website ( https://tensorflow.org/get_started/os_setup.md#installing_from_sources)?

They recommend not building from HEAD since it *might* be unstable. And bazel in the AUR is 0.1.0 which is the version they test against, and the version your PKGBUILD creates.

If it wasn't in the AUR already I would recommend you create a package for it separately. :p Apparently it can be useful...

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

...

- Another requirement by the project is running a ./configure script before building. I did this in prepare(), but the script requires user input. Is this a problem, or should it continue automatically?

./configure should be part of build()

prepare() is for things like: applying patches, replacing "python" with "python2", initing git submodules, and configuring them to fetch from a source=() clone,

etc.

Anyway, I know linux-ck allows you to set an option to run `make nconfig` during prepare() -- same deal with the linux package in core, except there it needs to be uncommented. makepkg won't break when requiring user input. But that ideally should be limited to situations where there are valid choices that need to be made -- it looks like you can simply export the right answers via an environment variable.

Okay thanks! I didn't know that.

...

- Finally, I noticed that during build, the CPU usage spikes to 100% because bazel parallelizes things. On my machine this caused gcc to crash at some point. Do I need to notify the user about this possibility?

I don't think so. Either they want to build it and they'll live with it, or they don't. I haven't seen warnings like that for other packages. I guess it is assumed people will make sure they have enough CPU and RAM if they want to compile large projects.

I've found an option in bazel to limit the amount of parallel jobs; perhaps that's fine as well.

...

Kind regards, Pieter Robyns

You should add protobuf to your source=() array, and fix line 36 to refer to the "google/protobuf" submodule -- not the "protobuf" submodule.

Ah I see, that probably explains why the protobuf source got cloned and then ignored when I added it to the source array :).

And why are you using /tmp to create the pip package rather than using a directory inside the build directory?

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

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

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 :

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