[Bug 219609] [NEW PORT] science/tensorflow: Computation using data flow graphs for scalable machine learning

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219609

--- Comment #6 from Jov <amutu at amutu.com> ---
(In reply to Kubilay Kocak from comment #5)
Thanks for your review,from your comment I learn more about freebsd ports,I
appreciate it! My reply is inlined:

>Initial review:

>1) USES=python implies {RUN,BUILD}_DEPENDS on Python (can remove python:lang/python). Additionally, use of python:lang/python is always incorrect, as it only means 'depends on the `python` symlink' not 'depends on python'. Only use USES=python:<args>
will fix

>2) Upstream stipulates Python 2.7 *and* 3.3+ support. USES=python:2.7 limits it to 2.7 only.
will fix by using USES=python:2.7+,and test python3.

>3) Regarding BROKEN (${OSVERSION} < 1100101):

>3a) clang and llvm 3.8 exist in ports and can be depended on. If there is nothing intrinsic or super-complex preventing other versions of FreeBSD from building tensorflow, it should do so.
see blow 3b

>3b) If clang is not a requirement for building tensorflow, it should not be a specific dependency. I see no mention of it on the 'building tensorflow from sources' document, but further, there *is* mention of builds with GCC, which motivates this comment.
I have try to use gcc but it is failed for bazel to find gcc.If I set
--compiler=gcc-5.4.0,bazel report error:
(cd /usr/ports/science/tensorflow/work/tensorflow-1.1.0 && bazel
--output_user_root=/usr/ports/science/tensorflow/work/bazel_ot build
--compiler=gcc-5.4.0  --config=opt
//tensorflow/tools/pip_package:build_pip_package --verbose_failures)
ERROR: No toolchain found for --cpu='freebsd' --compiler='gcc-5.4.0'. Valid
toolchains are: [
  --cpu='armeabi-v7a' --compiler='compiler' --glibc='armeabi-v7a',
  --cpu='local' --compiler='compiler' --glibc='local',
  --cpu='darwin' --compiler='compiler' --glibc='macosx',
  --cpu='freebsd' --compiler='compiler' --glibc='local',
  --cpu='x64_windows' --compiler='windows_mingw' --glibc='local',
  --cpu='x64_windows' --compiler='windows_msys64_mingw64' --glibc='local',
  --cpu='x64_windows' --compiler='windows_clang' --glibc='local',
  --cpu='x64_windows' --compiler='windows_msys64' --glibc='local',
  --cpu='x64_windows_msvc' --compiler='cl' --glibc='msvcrt140',
  --cpu='ios_x86_64' --compiler='compiler' --glibc='ios',

After read this,I think I need to write a toolchain config to work with gcc: 
https://github.com/bazelbuild/bazel/wiki/Building-with-a-custom-toolchain

>USES=compiler:<args> should be used if a specific feature is required (See Porters Handbook -- USES -- compiler for details [1])
will fix after I solve 3b.

>4) Vendored dependencies should be extracted/removed and those ports/packages in the tree depended on instead.
tensorflow use bazel manage dependencises.
the tensorflow-1.1.0/tensorflow/workspace.bzl contains dependencises info like
this:
native.new_http_archive(
      name = "org_pocoo_werkzeug",
      urls = [
         
"http://bazel-mirror.storage.googleapis.com/pypi.python.org/packages/b7/7f/44d3cfe5a12ba002b253f6985a4477edfa66da53787a2a838a40f6415263/Werkzeug-0.11.10.tar.gz",
         
"https://pypi.python.org/packages/b7/7f/44d3cfe5a12ba002b253f6985a4477edfa66da53787a2a838a40f6415263/Werkzeug-0.11.10.tar.gz",
      ],
      strip_prefix = "Werkzeug-0.11.10",
      sha256 =
"cc64dafbacc716cdd42503cf6c44cb5a35576443d82f29f6829e5c49264aeeee",
      build_file = str(Label("//third_party:werkzeug.BUILD")),
  )

And the count of dependencies is bigger than normal ports： 
grep -c 'sha256 =' workspace.bzl 
90
some dependencises even are not available on FreeBSD ports,like grpc.
It is a lot work to make this fixed and need to patch the bazel config ,this
will make future update difficult also.

>5) It's unlikely that all python dependencies are both RUN and BUILD dependencies. Please make these as accurate to their actual dependency types as possible.
will fixed

>6) -march=native should not be used for CC/CFLAGS. Binary packages are built from ports and build host CPU architecture has no bearing on end-user hardware, which may be different.
will fixed by using $CFLAGS

>7) configuration (in this case ./configure) steps should be run in the do-configure target, not the build target. Additionally and ideally, using CONFIGURE_TARGET and other CONFIGURE_* variables, without requiring a custom do-configure target override. If bazel is a pre build or 'configuration' step, it should be done in the configure target as well.
I hope to do this as you say,but the configure of this port is not gnu
autoconfig or similar,it is a bash script! It used to read user input from
stdin and set some variables then do bazel fetch.
I will fix this by moving configure to do-configure target.

>8) Patching of WRKSRC files should occur in {pre,post}-patch target, not build target.
As 4 and 7 mentioned, the configure will fetch all dependencises and the patch
is for the grpc and protobuf which only are available after configure.
So I will fix tis by moving patch to post-configure target.

>9) Was using the port/package of pip tested rather than configuring/building the  bundled tensorflow/tools/pip_package? The former should be used if and where possible.
yes I understand.but there is no pip package for freebsd,tensorflow offical
suport 
 is linux and macos.tensorflow/tools/pip_package will build one，it will include
all the dependencises python lib and C/C++ libs to the pip package,you can see
the pkg-plist.

>This port requires additional QA iterations
I will setup poudriere to test this when all of the above fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.